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Welcome to the Academy of Program and Project 
Leadership (APPL) and ASK Magazine . APPL helps 
NASA managers and project teams accomplish today's 
missions and meet tomorrow's challenges by providing 
performance enhancement services and tools, supporting 
career development programs, sponsoring knowledge 
sharing events and publications, and creating opportu- 
nities for project management collaboration with univer- 
sities, professional associations, industry partners, and 
other government agencies. 

ASK Magazine grew out of APPL's Knowledge 
Sharing Initiative. The stories that appear in ASK are 
written by the “best of the best'' project managers, 
primarily from NASA, but also from other government 
agencies and industry. These stories contain knowledge 
and wisdom that are transferable across projects. Who 
better than a project manager to help another project 
manager address a critical issue on a project? Big projects, 
small projects — they're all here in ASK. 

Please direct all inquiries about ASK Magazine editorial 
policy to Jessica Simmons, EduTech Ltd., 8455 Colesville 
Road, Suite 930, Silver Spring, MD 20910, (301) 585-1030; 
or email to jsimmons@edutechltd.com. 


ASK ONLINE 

http://appl.nasa.gov/ask 



EXCELLENCE AWARDS 


2 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 


in this issue Jessica Simmons 


Knowledge, for the Taking 


Immature poets imitate; mature poets steal 

— T.S. Eliot 


True, I'm a writer, but the Knowledge Sharing 

Initiative has taught me that the same sentiment applies 
for project managers: Take from the lessons and 
accomplishments of the best. And we're not talking 
imitation — there is no flattery here — this is all-out 
thievery. Make someone else's story your own story, 
make someone's lessons learned your own. Gather all 
the tidbits of best practices and leadership to become 
integral parts of your own project management style, 
not to be goals you strive to reach. Take knowledge, live 
it, and claim it as your own. 

The first time you do it, you might look over your 
shoulder a little. There might be some guilt attached 
to learning from the stories of the best of the best 
and slipping the lessons quietly into your proverbial 
pocket. In Larry Goshorn's article, Knowledge Stealing 
Initiative , he describes this coming-to-terms with 
Knowledge Sharing. The difference between that and 
a misdemeanor? NASA's Academy of Program and 
Project Leadership (APPL) Master's Forum presenters, 
workshop participants, and storytellers — they want you 
to use their stories and lessons and experiences! They 
are holding them out to you, leaving them unattended 
with your name on them, hoping you won't have to 
stumble down the same difficult roads if they could just 
hand you their conclusions. 

You're already familiar with most of the ways that 
APPL works with project managers like you to get 
knowledge out there for the taking. In future issues 
you'll see how we're continuously changing to make 
sure you always get the valuable information that 
you need. During the coming months we'll introduce 
you to experienced project managers who are joining 
ASK's editorial staff to add relevance and credibility 
to its stories. In 2005, we'll begin a quarterly publica- 
tion schedule allowing us to add more stories, more 
practices, and more knowledge in each issue for you 
to pillage. 


In this issue of ASK alone you'll find out how 
applying Earned Value Management to projects can 
help turn them around. You'll read the lessons one 
retired NASA PM learned throughout his career and 
see how far project management at NASA has come 
over the years. You'll absorb the knowledge that many 
people on a project have to offer and how to balance 
work and family during collocation. You'll find an 
illustration meant to stimulate discussion about APPL's 
Knowledge Sharing Initiative. And that's just what 
you'll see in print... 

Go to the APPL website and you'll find much 
more knowledge to steal. (Of course, we prefer to call 
it collaboration.) Search the ASK archives for the many 
lessons of issues past. Take a look at the Master's 
Forum stories and slides, and experience them without 
stepping foot out of your office. Click on links to 
other project management resources — most recently 
we've established a content-sharing relationship with 
GovSig's online publication — and see what's going on 
in project management beyond the world of NASA. 

It may seem a little counterintuitive at first — we're 
told plagiarism is punishable and identity fraud even 
worse! But fight these urges to play it safe. Use the 
many resources that APPL makes available. Grab what 
you can, slap your name on ideas that were someone 
else's first, call up a story as if it were part of your own 
project management past. Start here and now with 
these very pages. And if you're still feeling guilty, make 
sure no one is looking. • 
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JOHN BRUNSON of the Marshall Space Flight Center, 
Systems Management Office, is a member of the 
NASA Program Management Council Working 
Group. He supports the Agency's Chief Engineer 
g9 Office and MSFC in the review/development of 
Agency and Center Program/Project Management 
and Systems Engineering policy. He led the development of MSFC's 
Project Management and Systems Engineering Handbook as well 
as in-house training modules in these areas. He served as project 
manager for three separate microgravity payloads that flew on various 
Spacelab missions. Prior to his project management experiences he 
served as the Integration and Test Team Lead for the Tethered Satellite 
System Mission. His career with NASA began in the late 1980s as a 
member of the Space Shuttle Main Engine Engineering Team. 


DR. MICHELLE COLLINS works in the Spaceport 
Engineering & Technolog}' Research Group at 
Kennedy Space Center. She has more than twenty 
years experience in aerospace spanning engineering, 
R&D and project management. She is on the 
Florida Institute of Technology Department of ChE 
Industrial Advisory Board, the National Fire Protection Association's 
Technical Committee for Haion Alternatives, and the United Nations 
Environmental Programme Haion Technical Options Committee. 

^ JOHN DEL FRATE has 10 years of project manage- 
ment experience with the development and flight 
testing of Uninhabited Aerial Vehicles (UAVs) 
\&* I under the Environmental Research Aircraft and 
Sensor Technology (ERAST) Project During that 
time, he was associated with the development of 
Perseus A, Perseus B, Altus, Pathfinder Plus, Theseus, Helios, and 
the Solar Powered Formation Flight aircraft. Currently he serves as 
Project Manager for the High Altitude Long Endurance Remotely 
Operated Aircraft (HALE ROA), a NASA Vehicle Systems Program 
sub-project which will continue the development of UAVs for use in 
the stratosphere. 



1 1 HECTOR DELGADO is Division Chief of the 
Independent Technical Authority in the Independent 
Technical Authority and Systems Management 
^ j Directorate at the Kennedy Space Center. Previously 
A Hector was the Division Chief of Process Tools and 
B 9 Techniques in the Safety, Health and Independent 
Assessment Directorate. In 1995, he served as Senior Technical Staff to 
the NASA Chief Engineer at NASA Headquarters in Washington, D.C. 
He has received many honors and awards including the Exceptional 
Service Medal, Silver Snoopy Award, and various achievement awards. 

DR. OWEN GADEKEN is a Professor of Engineering 
Management at the Defense Acquisition University 
where he has taught Department of Defense 
program and project managers for more than 
twenty years. He retired from the Air Force Reserve 
as a Colonel and senior reservist at the Air Force 
Office of Scientific Research where he helped manage the basic 
research program for the Air Force. He holds adjunct faculty appoint- 
ments at the Federal Executive Institute and the Center for Creative 
Leadership. Owen is a frequent speaker at project management confer- 
ences and symposia. 

DR. MICHAEL HECHT has been with NASA since 
1982 at the Jet Propulsion Laboratory GPL). He is 
instrument manager and lead investigator for the 
MECA soil-analysis payload on the 2007 Phoenix 
mission to Mars, reprising a role he played on the 
cancelled 2001 Mars Surveyor Lander mission. In 
the course of his JPL career, he has served in line, program, and project 
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management, and has participated in research ranging from funda- 
mental semiconductor physics to martian geophysics. 


JODY ZALL KUSEK coordinates rcsults-based 
management at the Africa Region of the World 
Bank. She is currently involved in supporting the 
efforts of several African governments to move to a 
focus of performance-based management. She has 
spent many years in the area of public sector reform, 
serving the Vice President of the United States, the U.S. Secretary' of 
the Interior and the U.S. Secretary of Energy in the areas of Strategic 
Planning and Performance Management. 



DR. GERALD MULENBURG is a member of the 
Systems Management Office at the NASA Ames 
Research Center in California specializing in project 
management. He has project management experi- 
ence in airborne, spaceflight, and ground research 
projects with the Air Force, industry', and NASA. He 
also served as Executive Director of the California Math Science Task 
Force, and as Assistant Director of the Lawrence Hall of Science. 



JOAN SALUTE is the Associate Director for Projects 
in the Information Science and Technology 
Directorate at the Ames Research Center. Joan 
currently is on detail to NASA Headquarters. Joan 
previously was the Associate Director of Aerospace. 
She has managed many NASA projects including 
those involving flight testing of thermal protection materials, commer- 
cial technology, commercial applications of remote sensing, and 
remote sensing science projects. Joan has been at Ames for 22 years, 
and recently completed the Sloan Fellowship to attend the Stanford 
Graduate School of Business. 



HARVEY SCHABES is the Systems Management 
Lead in the Systems Management Office at NASA’s 
Glenn Research Center. He is responsible for 
providing oversight for independent assessments 
of programs and projects and for defining Center 
strategic plans and policies. He is also leading the 
Knowledge Sharing activities at GRC in collaboration with APPL. He 
started his career with NASA in 1983 in Icing Research, and since 
then has served in numerous organizations in support of the Space 
Station Program. 



CHARLIE STEGEMOELLER has served as the 
Associate Director, Space and Life Sciences 
Directorate, Office of Bioastronautics at the 
Johnson Space Center since 2002. The Office for 
Bioastronautics is responsible for coordinating and 
implementing the NASA Bioastronautics Strategy — 
the pursuit of tools, techniques, and policies to reduce risks, improve 
efficiencies, and return benefits to earth through the conduct of human 
space flight operations and research. He joined JSC in 1985 and has 
served within the JSC Comptroller's office, the former Space Station 
Freedom Project Office, and as a key member of the NASA/Mir Phase 
One Program. He received the NASA Exceptional Service Medal in 
1996, and became a member of the Senior Executive Service in 2002. 



HUGH WOODWARD is the President of Macquarie 
Business Concepts, a consulting firm specializing in 
effective project portfolio management. Before this 
position, he had a 25-year career with Procter & 
Gamble. He served as the Chairman of the Project 
Management Institute (PMI) for consecutive terms 
in 2000 and 2001. He was elected to the Board of Directors in 1996, 
and before being elected as the Chair, served as vice chair and in 
several other key leadership roles. 







from the director s desk Dr Edward Hojfman 


Knowledge and Meaning through Visualization 


The soul never thinks without a picture 

— Aristotle 


This issue features a visual depiction of the Academy 
of Program and Project Leadership (APPL). I imagine 
a variety of initial reactions to the drawing. One 
might be, "What is a cartoon doing in a magazine 
about project management?" Or perhaps, "Wow, nice 
colors — and fun." Another may be to closely search the 
image for signs, symbols and meaning. Still another, 
to read a new level of innovation and creativity into 
the picture. Undoubtedly, some readers will raise 
questions about the cost. 

Of course, any reaction is a sign of engagement. 
The stronger, the more energized the emotional and 
cognitive processing, the better. It is a sign of attention 
and interaction. For Fve heard it said, "You only need 
to worry if they don't care one way or the other." So 
what is the point of the picture? 

To stimulate interest, raise questions, promote 
discussion, and maybe raise a smile... That, at least, was 
my initial reaction when I was introduced to the work 
of Nancy Hegedus, who helps to create these drawings 
for Root Learning Inc. At the NASA PM Conference, 
I was first shown the work Nancy had been doing 
with the help of Goddard's Knowledge Management 
Architect, Dr. Ed Rogers. I was immediately drawn into 
the power of visualization as a tool for more effective 
learning, communicating, and conveying complex 
knowledge concepts. 

We need new tools in today's world, where 
information and data overwhelms by sheer volume. 
There are articles, pamphlets, communications, and 
white papers — all aiming to convince and influence. 
Reactions to these tend to be either avoidance or mind- 
numbing, heavy-eyed consent; the message never 
registers or enters the soul. That's one of the reasons 
that APPL's Knowledge Sharing Initiative (KSI) has 


turned to storytelling as a memorable way of transfer- 
ring knowledge, inspiring imitation of best practices, 
and spurring reflection. ASK Magazine’s recent fourth 
birthday marks an important milestone in APPL's 
continuing quest to provide ongoing support to project 
managers and to promote mission success. 

And similar to storytelling, the power of visualiza- 
tion is receiving increasing attention in recent years 
as a way to stimulate engagement. Pictures and visual 
graphs are viewed as one of the most effective ways for 
displaying, describing, and generating discussion about 
quantitative and technically complex information . 1 
Prototypes, models, and simulations are considered 
essential for stimulating innovation through open and 
engaging discussions . 2 There has also been extensive 
writing on the use of visual graphics, pictures, and 
cartoons to facilitate memory, creativity, openness, 
attention — and even well-being. 

For many of these reasons, I am excited to have a 
colorful visual depiction of the APPL world included in 
ASK. Without the addition of text or slides, the intent is 
to invite people into the world of the APPL mission — as 
well as its products, services, customers, and partners — 
in a fun and engaging manner. As project leaders strive 
to find ways to encourage engagement, learning, and 
transmission of knowledge, traditional technologies 
are proving to be as valuable as modern technologies. 
(But for those who want more information in the form 
of texts and slide presentations, we certainly have an 
abundance of those as well.) • 


' Tufte, Edward R. 1997. Visual Explanations. Graphics Press. 

2 Schrage, Michael. 2000, Serious Play: How the World’s Best Companies Simulate to Innovate, Harvard Business School Press. 
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If you could see the road ahead, you might just pass 
up a fantastic opportunity because you're blinded by 
the potential pitfalls. In my case, I was testing the 
project management waters at the NASA Dryden Flight 
Research Center after ten years of being a research 
engineer. I was an eager (but ignorant) rookie project 
manager (PM) and I was willing to engage in just about 
any project without knowing what it would entail. The 
assignment I accepted was to help NASA's Environment 
Research Aircraft and Sensor Technology (ERAST) 
Project, a partnership with a fledgling Uninhabited 
Aerial Vehicle (UAV) industry, to tackle stratospheric 
flight. I remember one of our industrial partners 
querying me about whether or not I understood what 
I was getting into. Like one of those bobble-head toys 
that have become quite popular, I nodded. But in 
reality, I didn't have a clue. His response was, "Hang 
on, it's going to be a wild ride." He was right. 

In retrospect, if I had clearly understood the ten 
years of pitfalls that were coming, I might not have 
"hung on." Now I can look back and say that I would 
not trade the experience for anything. 

The lows included the destruction of a number 
of UAVs on my watch. Later someone told me that we 
should not be surprised if we lost one UAV for every ten 
flights. We wrote many chapters in the book on what 
can go wrong with UAVs — and we are still writing. As 
you can imagine, each mishap was accompanied by an 
investigation. What an education! 

But as bad as the lows were, the highs were strato- 
spheric. We set a number of altitude records with the 
UAVs, and we performed a number of "first-of-a-kind" 
demonstrations with payloads. The highlight for me was 
the world altitude record we set in 2001 with the Helios 


aircraft on the Hawaiian Island of Kauai. We conducted 
our flight operations there, flying to a record altitude 
of 96,863 feet — 10,000 feet higher than any non-rocket 
propelled aircraft has ever gone. We did it on the power 
of the sun, and it was an unforgettable experience. 

The lowest low followed two years later, when 
we crashed this magnificent aircraft. So, I shared in 
both the glory and the humility that surrounded the 
ERAST project. 

For the ERAST effort, we had a small, close-knit 
team — an alliance — that partnered with different small 
companies and consultants. I viewed our collaboration 
as a partnership with these entities, as they were 
not contractors per se. We were working together 
under something called a Joint Sponsored Research 
Agreement (JSRA). It is a form of a NASA Space Act 
Agreement which is rarely used by NASA but provides 
a lot of flexibility. In this case, it allowed me to work 
closely with some very special people. We structured 
our agreement such that all work done by the various 
partners was done on a non-profit basis with each of 
the partners providing some cost-sharing. 

I learned some valuable lessons from this remarkably 
diverse group of talented and committed people who are 
largely responsible for making the ERAST project — and 
more specifically, the Helios project — a success. I would 
like to share a few of the lessons I learned, lessons I will 
take with me throughout my career. 

LEARN FROM THOSE BEFORE YOU 

Jenny Baer-Reidhart, the first ERAST Project Manager, 
displayed an enormous amount of courage. Some of the 
things she did to make the program a success required 
her to be bold and innovative. Because we were doing 
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Everything we are doing today is 


things differently, she often took heat and had to fight 
to stay the course. She always held her ground. 

She also had the ability to see the big picture. She 
created a work environment conducive to getting the job 
done and secured the funding, the company associa- 
tions, the places to fly, and the vehicles. Without her, 
the project never would have enjoyed the successes we 
did. There were lots of people involved, but Jenny really 
provided the leadership we needed. I learned an immense 
amount from her skills and strength as a leader. 

YOU’VE GOT TO EMPOWER YOUR TEAM 

Ray Morgan was (at that time) the Vice President of 
AeroVironment, the company that was our partner on 
Helios. He had been an ardent micromanager. A couple 
of years before ERAST came around, he realized that his 
management style was killing both him and his division. 
In order to survive, he decided to change himself and his 
division by managing a 180-degree turnaround. By the 
time this recovering micromanager and his team joined 
the ERAST alliance, Ray had empowered his team in 
such a way that they confidently used the strength of the 
entire team to make key decisions. 

After his transformation, Ray would participate in 
the decision-making process, but he no longer steam- 
rolled the team by saying, "No, it has got to be done my 
way." He was always willing to let anyone on the team 
have their say and to let the team processes dictate how 
a decision would be made. It was really inspiring to see 
the benefits of this type of management. Everyone had 
the resources, the responsibility, and the authority to 
do what they needed to do. As a result, we progressed 
very quickly and very efficiently. 

TRUST IS HUGE 

1 learned a lot from my relationship with AeroVironment, 
specifically from two people, Bob Curtin and Kirk 
Flittie. I wish everyone could have the opportunity to 
work with contractors that they trust the way I trusted 
these guys. Usually, with the government contracting 
structure, we spend an inordinate amount of time and 
money simply because we don't trust the contractor. 
There is probably a reason for every process or regula- 
tion used to govern them, but they seem ridiculous 


and wasteful to me. 1 started out treating the industrial 
partners like "contractors," but they soon earned my 
trust and respect. And it paid off for both the govern- 
ment and the industry partners, as we were able to do 
more technology development at a set level of funding. 

Not having to constantly monitor the contractors 
meant a much leaner operation; we were able to work 
smarter and faster. But we didn't throw the necessary 
checks and balances out the window. Instead, we used 
them at a level that allowed us to pour far more concen- 
tration into getting the job done. And because of the 
trust we'd established, I knew that our partners always 
had the best interest of the project in mind. I didn't have 
to always look over their shoulders to make sure the job 
was done right... ultimately we had the same goal. 

DON’T TAKE “NO” FOR AN ANSWER 

One of our independent consultants to ERAST was 
Dale Tietz, a very tenacious fellow. He is the type of guy 
that just does not take "no" for an answer. If the front 
door is closed, he asserts, "Try the back door." And if 
the back door doesn't work, "Try the windows." That's 
how he is. 

He's also the kind of guy who has a very thick 
Rolodex. He can walk into a meeting, and before long he 
is friends with everybody and scheming ways of taking 
advantage of the strengths of those in the room. Having 
a guy like that on your team adds a very special dynamic. 
He is constantly evaluating people and situations, and 
is willing to do whatever it takes to get things done. 
Watching him, I learned that project managers need to 
be tenacious — even when you are doing the right thing, 
doors will close — so you must never give up. 

STATE “THE MESSAGE” QUICKLY AND CONCISELY 

Somewhere along the way it occurred to us that we 
needed help making the right kind of project information 
available to the public. Now, I've never heard of another 
NASA Project bringing in a "publicist" to help, but that 
is exactly what we did. Pete Jacobs became our publicist. 
He would pop in and out, but when he popped in, it 
was because we were on the brink of some tremendous 
flight accomplishment. He taught us the importance of 
"the message." He taught us to use words that could be 
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small step along that larger journey. 


remembered by children, the media, decision makers, 
or the average Joe on the street. He wanted us to get that 
message out but also to get it right. He pointed out what 
should have been obvious: Stakeholders or the media 
don't have the time or capacity to absorb a longwinded 
technical speech. Fifteen seconds to say what you mean 
and say it right may be all you're going to get — especially 
if you're on-camera. 

I think that engineers, like myself, tend to really 
over-complicate things. We see the nuances in every- 
thing. People are always telling us to keep it short and 
make it consistent. Pete had us working on getting it 
down to short, concise statements that packed a lot of 
punch. He wanted everyone on the team to be able to 
give the same message. We were skeptical that there 
was any value to this exercise, but Pete was good and 
achieved unprecedented results. So as an engineer, 
whether I liked it or not, I learned that it's vital to say it 
right — and to say it concisely. 

KEEP THE IMPORTANT THINGS IN PERSPECTIVE 


the office. It's easy to let things get out of perspective. I 
always understood that some things are more important 
than work. But I learned that I need others — especially 
my wife — to help me judge how well I am doing. 

Part of keeping things in perspective is the ability 
to see an individual project as a step in a larger, ongoing 
journey. More than a hundred years ago, the Wright 
Brothers took a huge step: They convinced the world 
that we could actually achieve "heavier-than-air" flight. 
Their work built a foundation, one that those of us 
working in aerospace have been able to add to and 
build on. 

Our journey consists of taking steps based on 
prior steps, learning lessons based on the accumulated 
lessons of those who have gone before us. Everything 
we are doing today is a small step along that larger 
journey. These are the small lessons that have helped 
me shape and characterize my part in the long journey. 
They are the small road signs that I have posted for 
those who follow me. • 



This was the most personal lesson learned, but also 
the most important. By the time we were in the 2001 
deployment with Helios, my wife came to me and said, 
"1 think your work is more important to you than our 
family." I thought, "No way," and I argued with her 
quite a bit. I knew I had a pretty strong work ethic, but 
I thought that my family rated a much higher priority. 

I was convinced I was right, so as far as I was 
concerned it was a dead issue. But a couple of weeks had 
gone by when I made a decision that clearly favored work 
over family, and my wife was quick to call me on it. The 
bottom line was that even though I said that my family 
was the most important, whenever there was a conflict 
between my work and my family — work always won. If 
there was a scheduling issue, work always won out over 
my family. But I had become blind to this. I thank God 
that I started to see the light sooner rather than later, as 
it was hurting my marriage and my family. 

Of course realizing you have a problem doesn't fix 
the problem, but it's a start. I knew that I had to really 
make an effort to show what my "top" priorities are. It's 
an ongoing struggle for me, especially when I, like most 
PMs, don't have the ability to turn work off when I leave 


Lesson 

• Make it a regular habit to reflect on your experiences, to 
develop "small" lessons, and to share them with your peers. 


Question 

Is embracing a philosophy of "i ignorance is bliss" — that is, 
believingyou are better off not knowing the detrimental factors 
beyond your control — the right attitude for only rare situations, 
or should it be applied systematically? 





JOHN DEL FRATE has ten years of project manage- 
ment experience with the development and flight 


testing of Uninhabited Aerial Vehicles (UAVs). 


This work was done under the Environmental 


Research Aircraft and Sensor Technology (ERAST) Project. 
Currently, he Is Project Manager for the High Altitude Long 
Endurance Remotely Operated Aircraft (HALE ROA), a NASA 


Vehicle Systems Program Sub-Project which will continue the 


development of UAVs for use in the stratosphere. 


ASK 21 FOR PRACTITIONERS BY PRACTITIONERS 9 




J 



TABLISHIN 



THE MORE TIME I SPENT 
AT JOHNSON, THE MORE 
I REALIZED HOW EFFECTIVE 
IT WAS TO ACTUALLY 
COLLABORATE IN PERSON. 


PRESENCE 


BY JEFFREY MCCANDLESS 


THE SPACE SHUTTLE COCKPIT 

The Space Shuttle was developed in the 1970s using 
technology that was quite advanced for its time, including 
fly-by-wire components and multiple computer screens 
in the cockpit. Although the electro-mechanical gauges 
and cathode ray tube (CRT) screens soon became dated, 
no major upgrades were made to the cockpit for two 
decades. Part of the reason was simply that the original 
equipment was extremely reliable. However, it was also 
bulky and expensive to maintain. A glass cockpit was 
implemented in the shuttle to help remedy the obsoles- 
cence of many of the electromechanical gauges and 
dials, but that upgrade did not resolve the human factors 
and usability drawbacks of the cockpit displays. In 
part to address these deficiencies, NASA is developing 
a usability oriented modification called the Cockpit 
Avionics Upgrade (CAU). A key goal of the CAU project 
is to redesign the displays to improve the crew's under- 
standing of the on-board systems. 


WHICH BRINGS US TO ME 

In the fall of 1999, one of my managers at NASA Ames 
Research Center said, "There's a great new project 
going on at Johnson Space Center (JSC). They're 
upgrading the shuttle cockpit displays. How would 
you like to spend two weeks at JSC learning about it, 
then you could participate via telecons." I said, "That 
sounds great, but I have to talk to my wife. I already 
do a number of trips each year. I've got to balance this 
out and still keep this ring on my finger." It turned out 
that my wife was quite understanding. I already made 
a number of conference trips each year, so a two-week 
trip didn't seem too excessive. 

WE NEED YOU HERE 

When I talked with folks in person at JSC, they told 
me candidly, "Two weeks down here is great, but we'd 
really like you a bit more. Like every other week. For at 
least one year. What do you think?" 
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Uh oh. I realized they were right. The project 
seemed fascinating, but somewhat demanding. So 
back I went back to my wife — flowers in hand — and 
told her about this great opportunity. It was clear that 
I married the right woman. She said, "Go for it. But 
don't be leaving home every single week!" I promised 
that I'd be home every other week plus every weekend, 
and I kept my promise. In actuality, the trips down to 
JSC were typically from Monday to Thursday, every 
other week. The project blossomed, and over the 
last five years I've made dozens of trips to Johnson 
to work with astronauts, trainers, engineers, mission 
controllers at others at JSC. 

WORKING SIDE BY SIDE & FACE TO FACE 

This was very much a team effort, and it was 
quite helpful that I was present as much as I was. 
Typically, small groups of 5-10 people would work on a 
new display for a several-month period, and the 
co-location factor allowed for unscheduled, informal 
communication. Being there in person helped to reduce 
ambiguity surrounding decisions, speed up the project 


FOR ME, THE BASIS FOR 

THIS SUCCESSFUL COLLABORATION 


WAS 

FACE-TO-FACE COMMUNICATION. 



in terms of information exchange, and develop a team 
persona in which we were really aware of each other's 
strengths and weaknesses. 

The more time I spent at Johnson, the more I 
realized how effective it was to actually collaborate in 
person. Every time I had a question or needed assistance, 
there was someone who could help. They were happy 
to give me one-on-one support and training. If I was 
going to work in one of the space shuttle simulators and 
needed to understand the crewmember's roles during 
a malfunction, it was easy to find an astronaut trainer 
who would sit down with me. Without exception, the 
folks there were helpful and enthusiastic. 


And because of the many alliances I had from 
splitting my time between the two centers, I was able 
to keep Ames folks fully updated as well. A number of 
us made trips down to JSC to help support this project; 
one trip was made to address color characteristics of 
the shuttle cockpit screens. We collaborated well and 
were able to put together quite a few display formats. I 
remember thinking that the "One NASA" theory really 
held true on this project. 

DIFFERENT MEASURES OF SUCCESS 

For me, the basis for this successful collaboration was face- 
to-face communication. Though it was sometimes stressful 
being on the road so much, I really learned the importance 
of being present to work together and ask questions in 
person. Another measure of success was that in the midst 
of this project and traveling, mv wife and I managed to start 
a family. My oldest boy got a real kick out of visiting Space 
Center Houston when he was two to learn all about the 
"face futtle" which "goes way up in the sky." • 

Lessons 

• When practical, collocation and face-to-face commu- 
nication on a project eliminate misunderstandings, 
establish relationships, make information more easily 
accessible, and promote a team atmosphere. 

• Compromise is key to balancing both family and career 
goals. Knowing when to prioritize each is important to 
success in both aspects. 

Questions 

Is compromise really the way , and is it even possible in 
today's competitive environment? Or is alternation the key — 
periods of putting work first followed by periods of 
overcompensation at home? 



began 

work at NASA Ames Research Center in 1996 
developing image processing algorithms for 
advanced aircraft. Since 1999, he has been 
the Co-Lead of the Human Factors Team for 
the Space Shuttle Cockpit Council, which is 
responsible for designing and evaluating new 
shuttle cockpit displays. 
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I HAD NEVER THOUGHT OF MYSELF AS A THIEF, BUT THERE I WAS, PEERING AT 
STUFF THAT CLEARLY WASN'T MINE AND QUIETLY SLIPPING IT INTO MY “TOOLBOX" 
FOR MY OWN PERSONAL USE. IT WAS BROAD DAYLIGHT, AND I WAS IN PLAIN VIEW 
OF A LEAST A DOZEN PEOPLE. THE AUDACITY 1 . 


At least that's how it felt to me initially. I HAVE 
the honor of being on the Academy of Program 
and Project Leadership (APPL) Knowledge Sharing 
Feedback and Assessment Team (FA A), and as such. I 
am privileged to receive the feedback written by many 
of you as attendees of the Project Management (PM) 
Master's Forums. It is the intent of the FAA Team 
and APPL leadership to use this feedback as a tool for 
continuous program improvement. 

As a retired (sort of) PM in the payload contracting 
industry, I'm a big supporter of NASA's Knowledge 
Sharing Initiative (KSI), especially the Master's Forums. 
I really enjoy participating in them. Unfortunately l had 
to miss the 8th forum in Pasadena this past Spring, 
but I did get the feedback package for the Assessment 
Team work. So here I was, reviewing twelve pages of 
comments, reflections, learning notes and critiques 
from attendees of the 8th forum. 

THE EYEWITNESS ACCOUNTS 

The FAA's mission is to find the positives and negatives 
in the feedback and compile them for discussion. Shortly 
into the process of reading the comments, however, my 
mission changed. I found myself progressing through 
the feedback, agenda item by agenda item, and actually 


attending the forum vicariously through the feedback 
writers! I became engrossed in the content. I felt as 
though I was blindfolded at a fast-moving sporting 
event and the play-by-play was being described to me 
by many others around me. 

The feedback was incredibly detailed and well 
written, complete with application notes, doubts 
and potential pitfalls. Not surprisingly, I found 
myself learning rather than reviewing! I was actually 
taking away knowledge, forming opinions of my own, 
and developing questions, as though I had been 
sitting right there! That's why I initially felt like a thief. 
Actually I was experiencing remote learning, not only 
from the original forum presenters, but also from 
the feedback writers. 

CAUGHT RED-HANDED 

I myself have "stolen" lessons from various story- 
tellers and practitioners that have participated in APPL's 
programs over the years. I took the importance of story- 
telling as a means of conveying lessons learned — and also 
ways to implement this tool with a program team — from 
Annette Simmons's ASK 18 Special Feature, "Dressing 
up the Naked Truth." From Dr. Gary Klein, a keynote 
speaker at the 7th Master's Forum, I discovered the use 
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"WE DON’T HAVE TO BE THERE TO LEARN FROM IT. 
THE AVAILABLE MATERIAL ALONE IS VERY USEFUL." 


of "pre-mortems" as risk identification tools to help a 
team communicate effectively with a shared risk manage- 
ment philosophy. I learned ways to spot the predictors of 
successful program management behavior during the 
selection interviewing process from ASK feature writer 
Scott Tibbitts's article, "Tell Me About Your Lemonade 
Stand," which appeared in ASK 18. And these are just a 
few of the things I've taken away with me. 

As for the feedback accounts, it's clear that the 
8th forum was a huge success. As I reviewed the 
agenda topics, then read the presentation slides and 
the feedback, I found many of the common themes 
that always surface when Program/Project Managers 
get together to discuss successes and failures. A 
few of these common success factors were: effective 
communication both inside and outside your project 
team;the fact that "people" management — rather than 
"technical" management — is the most important factor 
for overcoming adversity; and the argument that leader- 
ship is founded on the principles of interpersonal 
relationships — including mutual respect, trust, open 
communication, and the creation of an environment 
that encourages new ideas and personal growth. And 
even though these are repeating success factors, there 
are always new stories, new thoughts, and new shared 
experiences dealing with their successful application. 

But my review of the forum material and feedback 
also revealed some newer topics as well. This knowledge, 
too, I snatched up like the proverbial starving squirrel 
after the world's last acorn; into my own PM toolbox 
they went! This included thoughts and concepts such 
as "the conductor does not make any noise, but 
gets the best possible music out of the orchestra." 

I learned new ideas for motivating teams and individ- 
uals and reflected on a debate about intrinsic vs. 
extrinsic motivation. I also read about the increasing 
importance of coaching and mentoring with notes 
for effective implementation of these concepts, the 
use of Test Readiness Levels (TRL) for managing 
Software project risk, considerations for establishing 
pro-active "coyote teams" versus re-active "tiger teams" 
and more. 

LIKE TAKING CANDY FROM A BABY 

This exercise in remote learning has been valuable 
to me. It has provided many new ideas for me and 
reinforced existing project management success 
concepts. It has illustrated to me, and hopefully to you, 


that we don't have to be there to learn from it. The 
available material alone is very useful. Coupled with the 
excellent feedback from the gracious attendees, it was 
almost as good as being there! 

And the folks at APPL are great at keeping the 
forum agendas and the presentation packages on their 
website, which can be accessed according to the forum 
number and date at http://appl.nasa.gov/businessunits/ 
knowledge/programs/master_forums.html. 

You may have also noticed that many of the Forum 
presentations also appear in narrative format in ASK 
Magazine , available online at www.appl.nasa.gov/ask. 
That means that this same knowledge, without the 
editorial comments found in feedback, is available on 
the APPL website to everyone, whether you attended 
the forum or not. Anyone can "steal" this knowledge 
sharing opportunity. 

I wasn't able to attend the 8th forum this past year, 
but I was able to take part in the knowledge sharing. 
To those of you who wrote the excellent feedback, 
I thank you. I'm looking forward to seeing you in 
San Francisco! • 

Lessons 

• When you are open to it, Knowledge Sharing becomes 
a tool for life, not a one-day workshop. Never underesti- 
mate the lessons you could learn from "communities of 
practice" composed of your experienced peers. 

• Reinventing the wheel isn't admirable if it's unneces- 
sary. Don't be afraid to steal, imitate, revise, and reuse the 
lessons and best practices of others. 

Question 

For learning to occur, errors, mistakes, and occasional failures 
must be accepted. How does one create the conditions that 
overcome human nature: the fact the " everyone wants to learn, 
but nobody wants to be wrong?" 


After over 28 years of program management 
experience, LARRY GOSHORN retired in 2003 
from ITT’s Aerospace/Communications Division 
as the Director of Space Programs. During 
his career, he successfully managed a variety 
of NASA payload projects, and he now works as a program 
management consultant in the Aerospace Industry. Goshorn 
previously published an article in ASK 18. 
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E arned value management ( E V M ) ...either you 
swear by it, or swear at it. Either way, there’s 
no getting around the fact that EVM can be one 
of the most efficient and insightful methods of 
synthesizing cost, schedule, and technical status 
information into a single set of program health 
metrics. Is there a way of implementing EVM that 
allows a program to reap its early warning benefits 
while avoiding the pitfalls that make it infamous to 
its detractors? That’s the question recently faced 
by the International Space Station (ISS) program... 


In 2002 , 1 joined the Station program's Assessments 

and Cost Estimation Office (ACEO), an organization 
established to perform the kind of early warning, 
" Where 's-my-program-headed?" assessments that 
few program managers have the time or staff to do 
thoroughly. 

By the time I joined the team, the ACEO had 
already established several unique tools with which to 
develop meaningful summaries and "What's-the-data- 
really-telling-you?" assessments for the ISS Program 
Manager. But one key program control tool remained 
missing: earned vlue based performance measurement. 
Leading the development and implementation of a 
program-wide EVM system became one of my early 
tasks, to no small extent because I volunteered that I 
understood EVM and believed in its utility. 


But you’ve got to use the data 

Mid-program EVM implementations, I soon discovered, 
are widely held by industry to be difficult endeavors at 
best. Although the ISS program was receiving monthly 
EVM data from its major contractors, nobody was tying 
them together to form a consolidated performance 
message. And even if someone had, only about half of 
the program's work would have been covered under this 
type of performance measurement. 

Few seemed to be using the contractor EVM data we 
were getting. Most managers were collecting it because 
it was required, not because they saw the value inherent 
in EVM reporting. The common feeling was that EVM 
was expensive, faddish, a royal pain in the posterior, and 
definitely not worth the effort. This feeling was expressed 
even more strongly by managers of work content not 
already encompassed by EVM reporting: "I'm getting all 
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the data I need through planned vs. actual costs, plus the 
technical updates I receive monthly from my leads... why 
do I need earned value?" 

That was only the beginning of the challenge. 
ISS was already squarely in operations, even as the 
last of the development effort was wrapping up. Some 
astute managers started asking the very good question 
of how meaningful EVM would be when applied to 
what they considered to be essentially level-of-effort 
work. Literature and Internet searches unearthed no 
examples of implementation of EVM on programs 
in the operations phase; nobody's corporate memory 
could recollect such an instance either. And it didn't 
help that what some veterans could remember was that 
a prior implementation of across-the-program EVM 
had been abandoned largely because the associated 
overhead was perceived to outweigh the benefits. 


at his next senior staff meeting. Having the Program 
Manager openly support our efforts in that forum was 
worth far more than any amount of lobbying we might 
have attempted to do. We had a sanctioned plan in front 
of everyone. Now we had to make it happen. 

Dealing with RMS 

Our philosophy of implementing an EVM system which 
maximized return on investment included minimizing 
the impact on managers' existing workloads. Our new 
Performance Measurement System (PMS — yes, we've 
heard all the jokes) was to be based on earned value 
concepts rather than to be a formal, certified EVM 
system. The idea was to use existing schedules, metrics, 
etc., rather than to reinvent the wheel. Considering that 
our program was largely in the operations phase, we 
also didn't expect to cover the high percentage of total 



► The overall program status was 
very close to the management 
team’s "gut feel.” k 


Then there was the issue of timeframe. All knowl- 
edgeable sources indicated that EVM implementation 
was often a multi-year endeavor. Once initiated, EVM 
systems were said to take at least four to six months to 
"settle out" and produce meaningful data. My team's 
marching orders were to have a tested EVM system in 
place in time for the start of the next fiscal year (which 
at that time was less than five months away) and to have 
results capable of withstanding outside scrutiny after 
the first month of baseline operation. 

Drumming up support 

A crucial first step was to develop an implementa- 
tion plan and gain the Program Manager's support. 
We outlined an aggressive schedule that supported 
conducting three dry runs of the new system. The 
Program Manager agreed to our plan, as well as to our 
request to present it to his control account managers 


work content under discrete earned value performance 
metrics that traditional EVM systems do. 

We concentrated on measuring performance for 
those tasks that, because of their risk, high cost, 
or visibility, could cause potential problems for the 
Program Manager. In this approach, we identified 
and closely watched those items that could become 
"gotchas." Thus our PMS became closely aligned with 
the program's risk management system. 

Another facet of making our PMS palatable to 
managers involved relieving them from as much of 
the implementation effort as possible. For example, 
our team shouldered the up-front work of developing 
a PMS process tool that would minimize the effort 
required for control account managers to make monthly 
EVM inputs and retrieve processed data for analysis. 
Our team drafted top-level, resource-loaded schedules 
for those control accounts that didn't already use one 
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in routine status reporting. We reiterated our "'low- 
impact implementation" message as we presented our 
pre-developed schedules and formats to managers and 
their support folks, then worked with them to answer 
questions and revise the schedules. 

Within ten weeks of the inaugural senior staff 
meeting, we had our process defined, and the first 
version of the PMS tool developed and validated. We 
also had top-level, resource-loaded schedules for all of 
our new control accounts, covering the three-month dry 
run period laid out in our PMS implementation plan. 
Similar schedules, covering upcoming fiscal year 2003, 
were in place. An innovative, more understandable 
way of looking at the EVM data — adapted from a DoD 
format — was incorporated into our tool and ready for 
debut with the ISS senior management. We developed 
methods of projecting end-of-fiscal year expenditures, 
as well as the split between unencumbered under-run 
and content-laden roll-through — taking into account 
such unorthodox factors as being in the operations 
phase. Convergence metrics were devised to track 
the system's "settling out" and to project when the 
EVM data would be mature enough to be considered 
meaningful for management decision making. 

But will the process work? 

Starting with the first dry run, we made monthly 
briefings of PMS results to the Program Manager and 
his senior staff. The initial results were interesting: Any 
given control account's data could be all over the map, 
but in aggregate the PMS estimate of overall program 
status was very close to the management team's "gut 
feel." The second month's dry run results showed more 
of the same behavior, and underscored what EVM 
experts had predicted: The data should be expected 
to vary widely from one month to the next until the 
system "settled out." By the third dry-run, however, the 
system already showed signs of stabilizing, particularly 
the ISS-level aggregate data. The Program Manager 
and his team were pleased with the initial results, as 
well as with our tool's data processing and presentation; 
the go-ahead was given to proceed with a baseline PMS 
for the new fiscal year. 

Success...! 

The initial baseline run, completed within six months 
of approval of our implementation plan, went as 
smoothly as anyone could have hoped for. The new 
resource-loaded schedules were completed just in 


time; the last-minute process and tool tweaks came 
together the same way. The financial and earned 
value data — once loaded into our PMS tool — resulted 
in a very believable ISS status that was in line with 
the senior managers' understanding of the program's 
technical, cost, and schedule situation. 

Perhaps most importantly, the EVM data sparked 
questions that forced managers to look a bit deeper 
into what was going on in their respective areas of 
responsibility. Those healthy discussions alone made 
all the previous months' efforts worthwhile. 

All of this was accomplished with the part-time 
efforts of a half-dozen people on our team, plus a 
couple of people from each of the ten new control 
accounts we created — and is being maintained with 
far less overhead than is commonly attributed to EVM 
systems. Our home-grown Excel®-based PMS tool, 
besides being "no-cost" compared with commercially 
available software, enabled us to tailor every thing at 
will to meet our analysis needs. Our PMS, including 
the unorthodox projection methods we developed, went 
on to predict fiscal year closing statistics to within a 
half percent a mere three months into baseline opera- 
tions. EVM has become a valuable tool in our assess- 
ment suite indeed. 

We swear by it. • 

Lessons 

• Rather than forcing a situation to conform to a 
solution that doesn't fit, flexibility and a willingness to 
try new things are necessary to tailor known techniques 
to the specific needs of a project. 

• Overcoming the project team's resistance to change 
can be facilitated by minimizing the direct burden that 
results from the implementation of that change. 

Question 

Why is a methodology developed more than a generation ago 
still unpopular in many well-developed organizations , and why 
does it still require a dedicated introduction effort? 


MICHAEL JANSEN leads the Assessments 
branch within the Program Planning 
& Control Office of the International 
Space Station (ISS) Program at the 
Johnson Space Center QSC). He is active 
in NASA training, knowledge sharing, and community 
outreach activities. 
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PUTTING EVM TD THE TEST 



TALK TD RNY PROJECT MRNRGER IN INDUSTRY OR GOVERNMENT 
RND YOU'LL FIND THAT TWO OF THE MOST EOMMDN COMPLAINTS 
RRE COST RND SCHEDULE OVERRUNS. 


BY JERALD KERBY AND STACY COUNTS 
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In many instances there is no forewarning; schedules 
slip, costs soar, and the project manager is faced with 
the near impossible task of explaining why each impact 
occurred. With contractors performing the majority 
of the work, the management job can become even 
more obscure. The simple lack of proximity to the 
contractor can limit effective communication. Add 
to that a mixture of cultural differences and a desire 
for the contractor to portray the most optimistic view 
of their performance, and you create an even more 
difficult task for the project manager. 

This was the scenario when the Habitat Holding 
Rack (HHR) manager at Marshall Space Flight Center 
(MSFC), Stacy Counts, was introduced to the overall 
concept of Earned Value Management (EVM). Faced 
with increased costs (which eventually resulted in 
decreased scope of the project), continued schedule 
slides, and several technical anomalies, she was 
looking for a way to gain a better handle on the 
project performance. 

As a component of the Space Station Biological 
Research Program (SSBRP), the HHR project is an 
integral piece of the Program content. The HHR is 
the first rack hardware to be delivered for the Program 
and has therefore been the first rack to move through 
the trials of test and verification — documenting 
anomalies and technical difficulties that will benefit 
the other SSBRP rack projects. For these reasons, 
the HHR maintained high visibility throughout the 
manufacturing and assembly process, continuing 


through test and verification activities. Needless to 
say, the higher visibility emphasized the need for 
improved performance on this project. And to improve 
project performance, Stacy first had to figure out 
how to measure the cost, schedule and technical 
objectives effectively. 

Enter the concepts of Earned Value Management 

As the principle center for EVM, MSFC was fortunate 
to have a group of experts — Jerald Kerby among them — 
whose knowledge of EVM was substantial, and who 
were willing to work with Stacy to apply the principles 
of EVM to her project. The overall goal was first to 
understand performance and better deal with the 
current overrun environment. 

Second, EVM would be implemented to improve 
the ways of managing cost and schedule concerns, and 
to plan ahead for future impacts that might result from 
the current situation. The process helps to measure 
performance in cost, schedule, and technical areas, 
and it would also help Stacy better identify her project 
risks. By measuring performance effectively and 
predicting a good percentage of issues/concerns upfront, 
mitigation plans could be put into place to help reduce 
or eliminate big impacts to the project. 

The first step: determining the status of the project 

Without an understanding of the current project status, 
there is no baseline from which to measure future 
evaluations. For a standard project that is in the early 


“ WHRT 15 ERRNED VRLUE MRNREEMENT IEVM1? 

EVM is a process that has been used for years by government and industry projects, predominantly by the Department of 
— Defense (DOD), to measure performance and health of the project. Government contractors use the process either as directed 

_ within the contract itself (currently NASA Policy Directive (NPD) 9501.3 but soon to be in NPR 7120.5C), or simply by choice. 

Unfortunately many projects never fully realize the potential of EVM and what it can do to help managers better understand 
the overall health of the project. EVM is not just a report! EVM is a tool that integrates the cost, schedule and technical 
_ requirements of a project. EVM also links these areas to the project’s risk management process. EVM requires discipline in all 
aspects of the project; it requires that the organization performing the tasks plan the work and then work to that plan. 

Obviously, some problems will occur that could not be predicted and therefore will not be a part of the initial plan; however, 
good initial planning followed by continual analysis and re-planning allows a manager to better mitigate issues and concerns 
_ that crop up. The use of EVM also helps the project manager in determining the current project status by answering questions 
such as: Are we on schedule? Are we on cost? Do the costs reflect the true accomplishments? What are our variances? 
EVM identifies trends that help a manager better predict where the project or a particular element is headed. EVM provides a 
_ method and data to establish a realistic Estimate At Completion (EAC) for the project. In essence, EVM gives personnel more 
reliable information to make better management decisions. 
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“Up until about three or four years 
ago, the people that had Earned Value 
Management on their contract would 
get a big, thick report and use it for 
a door stop. They just didn’t use the 
information." 

—JERALD KERBY 


stages of design development, an Integrated Baseline 
Review (IBR) is held. Much like a Design Review, 
the IBR is a review used to understand the project's 
performance measurement baseline (PMB) and project 
objectives. The IBR also enables project personnel to 
understand the PMB in three areas: cost, schedule 
and technical performance. Based on this review, the 
project identifies and documents the risks associated 
with elements of the project so that mitigation plans 
can be developed for each. 

But since the HHR Project was only two years 
from a completion date when Stacy came on board 
and recognized the need to use EVM, Jerald helped 
her to conduct a "mini-IBR," or a benchmark review. 
This helped them to assess the health of the project 
and to establish a more realistic PMB. The review was 
scheduled in such a way that it would not interfere with 
the contractor's regularly scheduled tasks. 

The entire process went smoothly, and every effort 
was made to alleviate intrusions that would cause cost 
or schedule impacts in performing this review. Once 
the review was completed, the entire team had a much 
better vision of the remaining tasks, and individuals 
came away with a clearer picture of their piece in the 
overall project flow. 

With contractors and government personnel 
working from the same baseline, the last step in the 
review was to come to documented agreement on 
remaining project objectives. The review resulted in 
a better-informed project team, and a group of people 
that learned to work together rather than having a 
"government versus contractor" mentality. 

The second step: working with the schedule 

In reviewing the PMB, schedule experts performed 
a review of the HHR schedules to ensure that good 


network logic was in place and that all task dependencies 
in the schedule were linked accordingly. Personnel 
from the Project Analysis Office at MSEC worked with 
Stacy and her team to determine whether the time and 
resources associated with each task were appropriate. 
Once the schedules were reviewed, specific issues 
dealing with missing network logic and unlinked tasks 
were discussed, and actions were taken to update the 
schedules as needed. 

During the schedule revisions the HHR team 
first realized the importance, and impact, of EVM. 
Although contractor personnel had established critical 
paths for every piece of the project schedule, an overall, 
high-level schedule did not exist to tie them together. 
Once a good schedule was developed for the overall 
project — linking all the major pieces of the project 
together — HHR personnel could better predict a date 
for completion of the work, as well as to develop a 
true critical path for the project. This schedule update 
also allowed for schedule changes to be added. These 
changes helped to identify clear critical paths for the 
project, and also helped the team to pinpoint an end- 
date which was tied to the impacts of those changes. 

The third step: applying the review concepts 

Good schedules certainly help to better plan a project 
in detail, but the implementation of that schedule is 
key to any project success. Once the initial review 
was complete — covering all functional areas of the 


“When you start using EVM, I think it 
is very important to sit down with your 
team to help them understand that 
this is not an antagonistic activity. The 
contractors need to know that you’re 
not trying to beat them up, but to 
establish a true story of the project. 
They may have a more optimistic view 
of what the project looks like at the 
end of the year, and I’m bringing in a 
different, more realistic perspective." 

—STACY COUNTS 


j. 
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“EVM gave me something to walk into 
a meeting with my contractors and 
speak to. I found that they would come 
in with their cost data and tend to put 
their best foot forward. I now have 
something substantial to back me up 
when I say, ‘Your past performance 
says you’re going to overrun — not only 
by what you’re telling me, but probably 
by more.”’ 

—STACY COUNTS 




project — the HHR team began to use EVM to regularly 
manage the project. 

The practice of EVM forced good planning by 
measuring work progress and providing the cost and 
schedule metrics to track project performance against 
the baseline plan. Using initial data, as well as each 
consecutive month's data as it was delivered by the 
contractor, the HHR manager could determine both 
cost and schedule variances and identify developing 
trends across the project's tasks. 

The fourth step: continuous review of data 

The primary data was submitted by the contractor 
via disk, loaded into a data analysis software tool 
(wlnsight), and a 5-page summary report was printed 
for review with the contractor each month. This report 
was reviewed alongside the standard Cost Performance 
Report (CPR) that the contractor submits monthly. 
With constant access to EVM data, both the contractor 
and Stacy's team were able to see a realistic picture of 
where the project had been, where it was headed, and 
how fast it was likely to get there. 

It works if you work it 

EVM is a management process that has been embraced 
by project managers around the globe with good success. 
It allowed Stacy to define a PMB for the project that 
was more realistic than the previous baseline. It also 
provided her with the necessary data to track performance 
and to ably discuss project impacts with higher-level 
management. This was the data the project team needed 


to back up that "gut" feeling that comes from years of 
project experience — experience that says you will almost 
always have schedule slips and cost overruns. 

While EVM doesn't make the problems go away, 
when implemented properly it can help to identify 
problems before they reach their full potential. Today, 
project success is no longer an unattainable goal. By 
using EVM data to guide a project on a monthly basis, 
objectives can be more easily reached. With good tools, 
solid upfront planning, and effective implementation of 
these tools, project managers can be better informed to 
make management decisions during the entire life cycle 
of their project. • 

Lessons 

• When all members of the project team — whether 
government or contractor — understand the objectives 
and work together from the same baseline, you are more 
likely to reach project success. 

• The ability to track performance and cost and schedule 
variances gives the Project Manager the information they 
need for a preemptive strike to slips and overruns. That 
is, they don't have to operate on their "gut feeling" alone; 
they have the data as soon as a problem begins. 

Question 

How can you change perceptions by introducing this tool to 
contractors as a benefit to the team , rather than a way of 
checking up on their peformance? 



JERALD KERBY is the EVM Focal 
Point for Marshall Space Flight 
Center, where he supports the 
implementation of EVM for the 
Center’s projects. 



STACY COUNTS manages the 
International Space Station’s 
Biological Research Project (BRP) 

Habitat Holding Rack (HHR). She 
credits the EVM tools available 
through the MSFC Chief Financial Office with 
helping her to establish a realistic approach to 
project planning, and a solid method for assessing 
the quality of contractor financial data. 
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EARTH H G VALUE 

BY GLEnn RHODESiDE 


in 2002 AnD EARLY 2003, KEnnEDY SPACE CEnTER COnDUCTED A PiLOT in WHiCH 
EiGHT in-HOUSE PROiECTS imPLEmEnTED EARnED VALUE ITlAnAGEmEnT (EVITl). 
BUT LET'S jUSTSAY WE WEREn'T WELCOHlED WITH OPEn ARfflS. 
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WE’D SAY. "WE’RE EVm. WE’RE HERETO HELP.’’ AflD rhAHAGEmEnT WOULD 


| 

I 


SAY/’ WE'VE GOT ALLTHE HELP WE HEED, THAflK YOU VERY fTlUCH!" IT WAS 
LIKE THAT TORi PETTY SOHG, "DOITT COBiE AROUflD HERE HO mORE." 


The project managers were given a half-day of EVM 

training. Although a portion of the project managers had 
some experience with EVM, the concept was completely 
new for some of them. The rest of that training day 
was spent helping them to start the base-lining process 
and answering any questions that they might have had. 
Slowly, we helped them to develop a baseline, and then 
conducted pseudo-integrated Baseline Reviews (IBR) 
where they presented their Work Breakdown Structure 
(WBS), their integrated resource-loaded schedules, their 
risks, and their risk mitigation plans. The intent, as with 
any IBR, was to get to an agreement with the project 
management so that everyone understood the baseline, 


AGAinST RESiSTAnCE 


what the project's risks were, how they were going to 
collect the data, and how they were going to use EVM 
to manage their projects. 

What we realized during the base-lining process and 
as the project personnel collected data and performed 
cost/schedule performance analysis was that half a day 


of training just isn't enough to learn how to use EVM. 
We recognized the need for at least two or three days 
to learn the basics. We also realized a few things about 
the culture and environment of project management 
in NASA, specifically in relation to implementing this 
type of change. We figured out that we had to anticipate 
some level of resistance within the organization, 
especially if they've never done this before. We had to 
be patient, work with them, and hold their hands a bit. 
It also didn't help that our financial systems did not 
collect actual costs in a manner useful for EVM. Lack 
of automated data collection meant manual manipu- 
lation of some data — an issue not present with most 
contractor financial systems. 

Lastly, it didn't help the 
cultural resistance when we 
came in halfway through the 
projects. EVM may benefit a 
struggling project, but for our pilot, there was a price 
to pay to come in after the start. There were already 
systems in place on the projects and we came in and told 
them that they had to change everything and start using 
EVM. We realized that to be most effective, EVM has to 
be introduced at the very beginning of the project. • 


B GLENN RHODESIDE performs 
systems engineering, risk management, 
cost estimating, operations analysis, 
and related analysis for varied programs 
and projects. For the past three years, 
he has been a member of NASA’s EVM 
Focal Point Council to set and coordinate 
policy, as well as share best practices 
and lessons learned. 
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I HAVE BEEN INVOLVED WITH PROJECT MANAGEMENT 
FOR FIFTY YEARS. RATHER THAN FOCUSING ON ONE 
PARTICULAR STORY, I’D LIKE TO TELL YOU THE LARGER 
STORY OF MY CAREER. THOUGH MANY OF THE PROJECTS 
TOOK PLACE OVER THIRTY YEARS AGO, THEIR LESSONS 
ARE STILL RELEVANT TODAY. 

I BECAME A PROJECT MANAGER AT AGE TWENTY-TWO AT 

Eglin Air Force Base. I managed the droning of the B47 
to fly unmanned, and I had zero experience to take on 
that task. What I learned is the real way you acquire risk 
aversion: I was scared to death that Fd fail. 

This developed a characteristic that I carried with 
me throughout my career. The strongest thing a project 
leader can feel, in terms of risk, is the risk of failing. 
So I took it upon myself to learn everything about the 
airplane and the guidance control system by searching 
out the best in the aerospace community. At that time, 
Lockheed was doing a modification of the aircraft. 
Boeing designed and built the aircraft, and Sperry was 
doing the guidance control system. I made sure that I 
spent hours and hours with each of them to understand 
exactly what I was responsible for. 

SETTING THE PATTERN 

The pattern that I established for my career was one of 
research and faith in the skills of other team members. 
Through the years as I worked on other projects, 
the philosophy I developed is that you can be very 
successful if you spend the time to organize yourself, 
find qualified people, and understand the objectives. 
Once you decide what you need to do, you can organize 
people around it. You can get the skills. That's the 
strongest way you can become risk averse — to be 
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dependent on the strengths of others and bring them 
into the program as best you can. 

When we worked on Viking, the first landing 
mission to Mars, it was done at Langley Research 
Center, which is really a technology center. Langley 
was selected because of its strong technology base, and 
the Jet Propulsion Laboratory (JPL) was busy with the 
Mariner and Voyager projects. 

We ended up using this to our advantage. Not only 
did we concentrate on finding qualified people, but 
we found that by doing the project at a technological 
center, we were able to get people who were strong in 
the technical skills it took to do the re-entry, to solve 
aerodynamic problems, and to develop the parachute. 
So Langley turned out to be a technological advantage. 

THE EARLY BIRD OPENS THE CHUTE 

But the parachute reminds me of the different ways 
in which the first and second Mars Missions dealt 
with risk. They were both successful, but the roads 
getting there were different. In 1969 we did a full- 
landed simulated test at White Sands. We simulated 
the spacecraft in the necessary ways and developed the 
parachute very early. The reason we did that was to 
make sure that the parachute got sized properly, since 
the whole integration of the spacecraft was going to be 
built around the size of it. 

The recent Rover Missions on Mars waited too 
long to do that test. They did it about nine months 
before they were supposed to launch and the parachute 
didn't fully deploy. So they had to go back and do a 
redesign of the parachute, but the whole spacecraft 
was designed and fixed. At that point there were many 
variables to look at and problems to solve, and the risks 
went up tremendously because of the limitations they 
had in changing the design. 


So not only should you organize yourself and get 
qualified people, but you have to do things early. You've 
got to build enough reserve in your thinking so that you 
can minimize problems. The other thing is: If you have 
a threat of cancellation over your head, or your project 
might be moved to another center, or parts of it are 
being deleted — you allow for that, and you adjust. If you 
stop working because you're worried about changes to 
your program, you start adding risks to it. 

THE GROUP EFFORT 

Also, you have to be disciplined in carrying out 
very critical analysis. Don't move on without it. On 
Viking, we brought the science community in early 
for the 1975 launch. They attended every design 
review and participated very strongly. We wanted their 
fingerprint on everything that was done from an 
engineering viewpoint. 

My mentor Jim Martin insisted that if this was 
going to be their opportunity for a scientific achieve- 
ment, then they needed to participate in the program 
all along the way. Would you believe that 72 scientists 
moved to JPL from their various universities for one 
year during the Viking Mission just because he said 
that was where the action was? He said, "If you want to 
play on my program, that's the way it's going to be." You 
can't avoid risk over the telephone. 

PLANNING FOR 

THE WORST-CASE SCENARIOS 

During Viking, we also developed about 500 scenarios 
of all the things that could possibly go wrong 
during the development and flight. We adopted a 
very pessimistic view and used these scenarios to 
establish various plans for cost offsets, budget shifts, 
and solutions to technical problems. 
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We did have a problem that I'm not proud of, but it 
also taught me something about risk. We had money 
problems, and we were told that we weren't getting any 
more money. The cost was fixed, and the schedule was 
also fixed since it was a planetary launch. 

Well, we had a risk problem related to a test. One of 
the problems with the fixed budget was that we weren't 
going to be able to perform the terminal-landing 
test. This was a very sophisticated full-systems test 
where we would drop the spacecraft through a Mars 
landing simulation. We had pitched the cost problem 
to headquarters, saying we needed $1.2 million dollars, 
and we were denied the money. So we were going to 
have to launch without the critical terminal-landing 
test — a very high-risk decision. 

Jim Martin accepted it at the time. He said, “Ok, 
as long as you hold my hand, I'll jump into the pool 
with you." So we made the decision to go ahead with 
it. We ended up being successful, but there was a large 
amount of risk attached. If we had failed we would 
have lost $1 billion dollars (and this was in 1970) 
because we couldn't secure the $1.2 million for the 
necessary preliminary test. That just doesn't make 
sense. It wasn't a schedule problem; it was strictly a 
cost problem. 

GIVE IT TO THEM STRAIGHT 

This is where I really learned a big lesson. As a 
project leader, you've got to take the problem before 
management and tell them the risks that they are taking 
by withholding funds. You've got to be tough and hang 
in there. At this point, we were seven years into the 
project. Jim decided to swallow hard, pray a lot, and 
cross his fingers that the test worked. We had a happy 
ending, but under other circumstances, it could have 
been a disaster. 

This is an example where management made the 
decision to take the risk against the security. I think 
that's the thing that has to change. We're in a high-risk 
business, and we have to approach it in a conservative 
way. But the Agency needs to realize that sometimes the 
failures make you learn and progress. 

I'm not saying that you set out expecting to fail, 
but there is such a thing as so much risk-aversion 
that you don't do anything. You've got to maintain a 
healthy amount of it and move ahead. And these are 
just some of the strategies I learned over my fifty years 
that have helped me to do that. • 



There have been times when I’ve taken over 
a project in the middle, and also times when 
the project has been in the formative stages. 
In every case, I’ve gone off-site and started 
to look at— and fix— duplication. Everybody 
has to be in first grade again. I say, “Stand 
up and tell me what you think your job is.” 
They do that. Then you start listening. 

Sometimes I’d find out that two or 
three people were doing the same thing. So 
I started to fix it. I’d find out where the holes 
were, where there is somebody who is not 
doing anything. So you work it out so that 
everyone is clear about exactly what they 
are doing and what the goals are. 

Then you have to empower people to 
build a high-performance team. This team 
has to be willing to communicate and tell 
you exactly where you are. You do this by 
dealing with the complete human circle: the 
social aspects, the commitments, the truth- 
fulness, the relationships, the passion— all 
the things that we measure in people. Then 
you can take their technical skills and apply 
them in a way that really drives the system 
to success. 

A process doesn’t get the spacecraft 
built. A logo or a motto doesn't make it 
happen. It's people. 


Lessons 

• Sometimes pessimism can help to reduce risk. 
Planning for possible problems — and developing a cost 
and schedule-efficient way of dealing with them — can 
provide an important project “safety net." 

• A small amount of funding is never worth the failure 
of a large-scale project. Project managers have to fight to 
get the resources they need to do things right — not cross 
their fingers and hope for the best. 

Question 

In a situation where mistakes and misjudgments can cost 
millions of dollars , how do you strike the right balance between 
healthy risk-aversion and playing it too safe? 


ANGELO “GUS” GUASTAFERRO has had a lengthy career 
in Program and Project Management, 
both at NASA and with private industry. 
His previous story, “Bringing Up Baby,” 
was printed in ASK 17. 
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This little weapon, though, was notjltst representative 
of a transition in my career. It was a paradigm shift for 
the Air Force. Traditionally, we've held the American 
outlook of “bigger is better." Look at our cars, our 
houses. So this program was symbolic of a culture shift. 
It was important to make a switch to smaller weapons, 
because the Cold War was over, and we were going into 
smaller areas. Collateral damage became a big issue, 
and we were limited in space on the aircrafts. 

BUT CAN SMALLER GET FUNDED? 

Being naive, I thought, "We're going to start up a 
program. Somebody must want this. They'll give me 
money, we'll lay out the strategies, and we'll get started." 
I was frustrated when it didn't go that way. Somebody 
told me that it takes patience to be a Program Manager. 
I thought, "Well, I'll work on that." 

While I was working to obtain funding to develop 
an acquisition strategy and to build coalitions, I was 
also trying to make people understand what we were 
doing. The weapons side of the house doesn't get a lot 


of money thrown down to us compared to our aircrafts. 
So at first I had a very small team of only four people. 

The four of us worked day in and day out coming 
up with acquisition strategies and working with our 
warfighter users to develop requirements. But every 
year we'd find out that we were just under the cut and 
that we wouldn't get funded. And every year I would 
think, "It's time for me to leave." But I kept going, kept 
trying to build it. After three years of trying to start 
this, I had laid out about 20 acquisition strategies in 
any flavor you wanted. I had all kinds of choices for 
anybody that came along. 

THEN IT SNOWBALLED 

It was Super Bowl weekend of 2000 — not that I watch 
the Super Bowl, but my husband was watching it — and 
I was working on getting my numbers together. I had 
gotten a call that Friday afternoon saying that General 
Jumper, who at the time was the Commander of Air 
Combat Command, wanted to pursue development of 
this weapon. So they said, "We're going to fund it." 
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I was so excited. I went around briefing my strategy 
and got things going. But what happened was that 
when this program started, I was in my comfort zone. 
Then my span of control went haywire overnight. Over 
a period of two months, I went from managing four 
people to 30 people. 

At this point, I had made every decision about 
the program along the way. It was my vision, my baby, 
my masterpiece. I knew everything about this system. 
And I liked it that way. I loved being able to make every 
decision and to tell everyone what 
they needed to do to make my 
vision a reality. When 1 went 
into the teams, everybody knew 
how I operated: I tell you what 
to do, and you go do it. 

Then I was sitting around 
the table one day in a meeting 
trying to get our Request For 
Proposal (RFP) together. What 
I found is I had driven these 
people to expect me to make 
every decision. All of a sudden, 

I got overwhelmed. I had about 
25 people around the table, and 
I'm saying, "We need to have these factors developed. 
I need you to write your section L, you to write 
your section M, you to write your instructions for 
the offer, and then bring it all back to me." They 
all looked at me and said, "How do you want me to 
do that?" 

I thought, "I'm in over my head. There is no way 
that I'm going to be able to do every one of these 
people's jobs, or tell them exactly what to do, or check 
all of their work." I just left the meeting. 

RELEASING THE GRIP 

There was a retired Colonel who worked for me as a 
support contractor. I used him as a sounding board 
a lot. I sat down at his desk and said, "Bill, I'm in 
trouble. All of these people expect me to make every 
single decision and tell them exactly how to do every- 
thing. I'm not going to have time to do it anymore." He 
said, "You've got to let go of this. You have no choice. 
Otherwise, you are not going to make it." 

It was extremely hard for me, because I felt such 
ownership of the program. I felt like I was giving up 
my firstborn when I gave it to these people to try to 
implement. But I called everybody back in the next day. 


They were waiting for me to give them instructions on 
exactly how to write up their RFP. I said, "Here's the 
deal. I'm not going to think for you anymore. We've 
got to get on contract in six months." I said, "If you've 
never done it before, you're going to learn now. I'm not 
telling you how to do it. You had better figure it out. I'll 
be happy to help you, but I can't do it all." 

1 was very nervous though. Here I was not tracking 
everything day to day. I wasn't right on top of it writing it 
myself. But by the end of the source selection, surprisingly 
enough, things had changed. Some 
of the people that wouldn't go 
to the bathroom without asking 
permission were up at the 
front of the room, coming up 
with their own methodologies, 
leading the pack, and making 
decisions. All of a sudden, they 
had emerged as leaders. 

A NEW UNDERSTANDING 

At that point, I was more proud 
of having let go than of doing it 
all myself. My focus had changed 
from the details, the implementation 
of developing every one of these criteria, and dealing 
with the contractors, to leading the people. 

When I realized that I had to do that, things got 
easier. You would think that it was an obvious thing, 
but sometimes you have to learn the hard way. Heroes 
are people that can come in, take over, and do it all 
themselves. But when you lead people, you don't have to 
do it yourself. You're leading them to the vision. 

I don't know that I necessarily ever would have 
gotten slapped in the face like I did had I just been on 
a normal program. After having gone from four people 
to 30 people in a two-month time frame — and having 
them staring me in the face, wanting to know every- 
thing to do — the light came on. No matter how good 
you are, this isn't a one-man show. There are no heroes 
in this. • 

LYNDA RUTLEDGE was an Air Force systems 
engineer on the Joint Air- to- Surface Standoff 
Missile (JASSM) during the source selection 
phase. After leaving JASSM, she managed 
the concept exploration and planning of 
the program that is now the Small Diameter 
Bomb (SDB). She is currently Deputy Director in the Precision 
Strike System Program Office within the Armament Product 
Group at Eglin Air Force Base, Florida. 


OVER A PERIOD OF TWO MONTHS, 
I WENT FROM MANAGING 

FOUR PEOPLE TO 
30 PEOPLE. 



30 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 



In a meeting facilitated by 
Goddard Space Flight Center’s 
Knowledge Management Architect, 
Dr. Ed Rogers, Root Learning Inc. 
teamed up with members 
of the Academy of Program 
and Project Leadership’s (A PPL) 
Knowledge Sharing team, Denise 
Lee and Therese Cooper. In a 
brainstorming session with Root 
Learning’s artists, together they 
worked to create an accurate 
illustration demonstrating the 
APPL vision. In its advanced 
stages, the drawing was sent to 
APPL Director Dr. Ed Hoffman 
and Deputy Director Tony Maturo 
for further suggestions. A few 
iterations later, APPL’s successful 
collaboration with Root Learning 
produced the final version of this 
customized “Learning Map.” 


Root Learning, a learning consulting organization 
with a background in strategic planning, recognizes 
the knowledge gap that frequently exists between a 
leadership team and the rest of an organization. Team 
members supposedly working toward the same goal 
don't always have the same vision of where the organiza- 
tion is headed — and they may not understand how the 
piece they are accountable for fits into the big picture. 

To address these complex problems within an organiza- 
tion, Root Learning utilizes the age-old tools of sarcasm, 
metaphor and graphics (much in the same way that ASK 
uses a traditional storytelling format.) The company is 


humorous drawings based on the inner workings of an 
organization. Their purpose is to put complex topics 
on the table, to stimulate discussion, and to ultimately 
give team members a common vision of where the 
organization is going and what role they personally play 
in getting there. 

APPL knows how effective it is to incorporate 
new and engaging techniques into its knowledge 
sharing programs. By collaborating with Root 
Learning, we were able to expand the knowledge of the 
organization and add one more of these techniques to 
our repertoire. 
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Career Development 
Performance Enhancement 
Knowledge sharing 
Applied Research 



To learn more about Knowledge Sharing and other APPL services, 
find contact information at www.appl.nasa.gov. 
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Root Learning Inc., is best known for creating “Learning Maps” like this one: humorous 
drawings based on the inner workings of an organization. Their purpose is to put complex 
topics on the table, to stimulate discussion, and to ultimately give team members a common 
vision of where the organization is going and what role they personally play in getting there. 









KeepinG 

promises 


BY GREGORY HOWELL 

THe projecT, a comPLex HeaLTHcare Facimy, was in mume. me 
money arm Time were Gone, but mere was PLemy of disttust anD 
mis-coormnaTion. 


Scheduling work seemed impossible; the design was 
filled with conflicts, and it kept changing. Supervisors 
were torn between finding work ready for today and 
trying to solve problems for tomorrow. It wasn't much 
fun, and the client was very unhappy. There was so 
much to do — and so little time — that it was hard to 
know where to start. 

Design issues dominated the weekly planning 
meeting, so I went there to listen and learn. After new 
issues were identified and discussed, the 
meeting turned to review the status of 
unanswered RFIs. These Requests For 
Information typically originate in the 
contractor organization and are used to 
define, manage, and track solutions. 

Going down the list, Carl, 
the contractor's project manager, 
spoke to Dan the architect. "Dan, we need to 
resolve RFI 173." Dan shook his head in agreement, 
and they moved on to RFI 204. I wasn't at all 
sure what had happened or how to interpret this 
brief interchange. 

After the meeting, I caught up with Carl and asked 
if Dan had promised to solve the problem. Carl was 
convinced that he had. I was not so sure, so we caught 
up with Dan and I asked, "Did you promise Carl to 
answer 173?" Dan was surprised and confused. "How 
could I?" he said. "I agree we need to get it resolved, but 
Carl owes me some vendor data before we can decide." 


Carl was taken aback; he had forgotten his promise 
to Dan. But after a quick discussion, both were back 
on track. 

Walking away, I asked Carl why he had framed his 
request, "Dan, we need to resolve RFI 173." He said 
this was a nicer, more team-friendly way of talking. 
He claimed, "It puts us in the problem together." Carl 
and I are pretty good friends, so I took him straight on. 
"Teamwork isn't about being soft and unclear," I told 
him. "It requires making clear requests 
and securing reliable promises. Don't 
be a wimp — ask for what you want. 
And don't be a flake — do what you say 
you are going to do." 

Coordinating work in projects and 
keeping projects under control is a 
matter of people making and keeping 
the commitments that release work to others in the 
right sequence. A project can be understood as a 
network of commitments that links the work of the 
specialists to the promise of the project and coordinates 
their action. Carl makes a request to Dan... Dan asks for 
vendor data. . . Carl asks his assistant. . . somewhere a request is 
mistaken for an opinion , or the nod of the head is interpreted as 
a promise. Planning systems can provide the structure 
and circumstance for planning conversations, but 
systems don't make work happen. People make work 
happen by making requests and keeping promises to 
one another. 


commiTmenTS are 
BeTween peoPLe. 
noTscHeDULes. 
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Don’T Be a wimP-asKFor wHaT you warn. 


There are ways to tell when you are making a 
reliable promise. Ask yourself if you can say one or 
more of the following: 

1. I am competent enough to perform, or 1 have 
access to competence. 

2. I estimated the amount of time (hands-on) 
required for this work. 

3. I have the capacity available to do the work and 
have allocated it to the task. 

4. I am not having a private unspoken conversation 
in conflict with my promise. 

5. 1 will be responsible; I'll clean up the mess if I 
can't deliver. 

Commitments are between people, not schedules. 
Project management as practiced today creates a 
"commitment-free zone," because it assumes that people 
will commit to centrally managed schedules without 
providing a mechanism to ensure their work can be 
done. So they give it their best, but something always 
seems to come up... "I tried, but you know how it is." 

This form of project management does not provide 
a mechanism to ensure that what should be done, can in 
fact be done at the required moment. Too often, promises 


made in coordination meetings are conditional and 
unreliable. It has been my experience that at times 
trust can be low and hard to build in this environ- 
ment. The absence of reliable promises explains why 
on well-run projects, people are often only completing 
30-50 percent of the deliverables they'd promised for 
the week. 

We all know what a promise is; we have plenty of 
experience makingthem and receivingthem from others. 
So what's the problem? The sad fact is that the project 
environment — like many other work environments — 
is often so filled with systemic dishonesty, that we don't 
expect promises that are reliable. Project managers 
excel when they manage their projects as networks of 
commitments and help their people learn to elicit and 
make reliable promises. • 


GREGORY A. HOWELL is co-founder and 
managing director of the Lean Construction Institute 
(LCI), a non-profit organization devoted to production 
management research in design and construction. 
Howell brings 35 years of construction industry 
project management, consulting, and university-level 
teaching experience to LCI. 
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DOCUMENTATION: 
NO SUBSTITUTE FOR 
COMMUNICATION 

IN THE 25 YEARS THAT I’VE WORKED FOR GENERAL CONTRACTORS , 
OWNERS, AND ENGINEERING FIRMS, I'VE RECOGNIZED THE 
REQUEST FOR INFORMATION (RFI) PROCESS AS A HUGE SOURCE OF 
WASTED EFFORT AND NEEDLESS CONFRONTATION 

BY JOHN STRICKLAND 
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PRACTICES CONTINUED 


So WHAT IS AN RFI? It was one of the first things 
I learned about back when I started my project 
management career with my first large construction 
firm. 1 learned how to use these forms as a 
convenient and effective means of documenting the 
many legitimate clarifications needed on a major 
project. However, like most other young engineers, I 
also learned to use the RFI as a weapon in the ongoing 
battle between owners, or their designer and the 
construction contractors. Recently, our project team 
has done a few simple things to greatly reduce the waste 
and frustration that comes from this type of battle. 

WHAT’S THE PROBLEM? 

The RFI form can be a great tool if used properly, and 
I certainly don't recommend that they be eliminated 
entirely. The RFI form was created to document the 
many clarifications that are commonly required on 
projects. Typically, the contractor uses the top half 
of the form to clarify — or request permission to vary 
from — the contract documents. The bottom half of the 
form is used to record the answer. But this seemingly 
simple process is plagued by a number of problems. 

From the contractor's perspective, RFIs are needed 
to secure information that should have been in the 
contract documents in the first place. The missing infor- 
mation keeps their crews from working effectively, and 
it makes hitting already demanding cost and schedule 
targets even more difficult. Owners, or their design 
firms, often view the RFI as a means of harassment. 
Both sides of the issue have legitimate complaints, and 
both sides cause most of their own pain. 

Considering that year after year these problems 
appear on countless projects across the country, the 
total wasted effort involved is beyond comprehension. 
To make matters worse, many of the problems (and 
many of the RFIs) are completely unnecessary and 
represent waste in its purest form. 

WHAT WENT WRONG? 

It is easy to understand how the RFI was transformed 
from a convenient means of documentation into a 
weapon of project administration. Just start with the 
owner/designer side of the contract: tough-minded 
contract administrators or field inspectors would 
require contractors to remove and replace work that 
didn't match the contract documents — even if there 
was no functional reason to require the re-work. 
Contractors quickly learned to document even the 



slightest variation. But they also learned to write as 
many RFIs as possible in order to substantiate future 
claims. I recall a general contractor's manager explicitly 
instructing his staff to maximize the number of RFIs in 
order to establish that the design was flawed. And I'm 
sure experienced project managers can cite many other 
examples of wasted effort. 

LOOKING FOR ANSWERS 

We have learned that life on the project does not need 
to be as difficult as we make it. And there are some ways 
that I've managed to avoid these difficulties by focusing 
on communications skills and creating a culture 
of collaboration. 

I managed to do this on one of my recent projects, 
a state-of-the-art facility constructed in the Pacific 
Northwest for one of the world's leading technology 
companies. Our scope was to install and connect 
hundreds of highly sophisticated machines in the 
shortest feasible amount of time. Contractors worked on 
very competitive fixed-price agreements and employed 
up to 1,000 craft employees at the peak of construc- 
tion. Although hundreds of RFIs were generated, there 
were remarkably few complaints (if any at all) about RFI 
turn-around time, which averaged about three days. 

OPEN YOUR MOUTH 

The key to our good experience was recognizing the 
difference between documentation and communication. 
RFI forms are great for documentation, but they are no 
substitute for conversations. Our simple rule was that 
nobody should receive an unexpected RFI. The first 
step in our RFI process was to discuss the issue with 
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the construction coordinator in charge of the work. 
Many of the potential RFIs were answered before they 
were ever written, and no effort was wasted getting them 
through the system. The RFIs that were necessary could 
be answered very quickly, because it simply documented 
an agreement that had already been made. 

REDUCING WASTE BY 
REDUCING NUMBERS 

Several other techniques were used to reduce the need 
for RFIs, including thorough pre-construction job walks 
and design reviews to make sure that everybody under- 
stood the scope. We made sure that the construction 
management and design teams had good access to 

THESE OPPORTUNITIES STEM FROM 
ESTABLISHING A COLLABORATIVE CULTURE, 
EVEN ON PROJECTS WITH RIGOROUS 
CONTRACTUAL REQUIREMENTS. 

one another and provided many different forums for 
communication. When RFIs were necessary, they were 
electronically routed and tracked. We learned that 
an electronic RFI system can be a good tool, but will 
certainly not eliminate all of the friction in the RFI 
system. It's easy to imagine the computer-based RFI 
tracking programs as simply more powerful weapons 
in the battle. 

AND EVERYBODY’S HAPPY 
Contractors were happy, because they got their answers 
quickly. The designers were happy, because they got far 
fewer poorly worded RFIs that were unnecessary in the 


first place. The owner was happy, because there were 
essentially no change orders due to the RFI process to 
cause delays, disruption, or field coordination issues. 
The entire project benefited from the effort to develop 
a collaborative culture, and we set new benchmarks for 
safety and schedule performance as well. 

The real lesson I took from this experience was 
what an amazing effect good communication can have 
on teamwork and project performance. Much of the 
conflict and confrontation that burdens the project 
team is largely unnecessary. There are countless other 
opportunities on our projects — from contracts to 
technical submittals — for improving project perfor- 
mance, as well as the quality of life for project team 
members. These opportunities stem from establishing 
a collaborative culture, even on projects with rigorous 
contractual requirements. One way Fve found to start 
effecting change is to take a look at RFI processes, 
as well as other processes where communication is 
the key. • 


ra has led numerous major design/ 
build and construction management projects within the 
microelectronics industry. He has developed a strong track 
record for completing projects ahead of schedule and under 
budget, and has helped pioneer numerous strategies that 
have dramatically improved “time to money” for clients. He has expertise 
in all phases of construction operations— including safety management, 
project controls, contract management and field operations-as well as 
the application of “Total Quality Management” and “Lean Manufacturing” 
techniques to complex construction projects. 
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In 2000, I transferred from a department of predominantly manufacturing people to one in 
which most people had an IT background. For my manufacturing colleagues, "meetings" were 
always face-to-face activities. 
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PRACTICES CONTINUED 




But the IT people, many of whom worked from home, 
made no such presupposition. And so even when I 
issued a meeting notice, with the location described 
in bold, somebody would inevitably remind me to 
“publish the call-in numbers." Faced with conducting 
meetings of one, or learning to conduct effective remote 
meetings, I chose the latter. 

I experienced more than my fair share of failures 
initially. But each failure prompted me to adjust my 
approach. I soon realized that the practices that make 
remote meetings successful are exactly those that make 
face-to-face meetings successful. But habits that result 
in poor face-to-face meetings are exacerbated in a 
remote environment. 
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Any meeting announcement needs to clearly state 
the location and starting time. Similarly, remote 
participants need clear instructions on how to access 
the meeting and when. Participants in face-to-face 
meetings can generally ask for directions if the 
announcement is unclear. Or the meeting leader can 
send a search party for late arrivers frantically trying 
to find a poorly marked conference room. No such 
remedies are available for remote meetings. A simple 
error in the telephone number or passcode can doom a 
remote meeting before it begins. 
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There is obviously no need to select a meeting location 
for remote meetings, but there are equivalent and 
important considerations. For example, the dial-in 
service and collaboration software, if any, must be 
reliable and capable of handling the anticipated number 
of participants. It must also be available for the required 
duration, and restricted to the intended meeting. We 
are all familiar with the confusion that results from 
two groups trying to use the same conference room 
at the same time. But it hardly compares to the havoc 
resulting from two groups trying to use the same call-in 
number at the same time. 
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This is due in part to the absence of the visual cues 
that signal a face-to-face meeting is ready to start. For 
example, it is obvious when the participants in a face- 
to-face meeting enter the room and sit down. Some are 
early, some are late. Some immediately begin talking, 
some enter quietly. Some sit down immediately, others 
chat quietly with friends or pour a coffee. Some are 
well-prepared with notes, others are consulting PDAs 
desperately trying to recall the purpose of the meeting. 

But the remote meeting leader must confirm 
everybody is present and ready to begin audibly. I 
typically do a roll call of expected participants, asking 
each person to respond individually. Or 1 read the list of 
people who have introduced themselves, and then ask, 
“Is anybody else on the call?" I then confirm everybody 
has access to the agenda and other documents. This 
may be as simple as confirming everybody received 
the documents emailed in advance. But if we are using 
collaboration software, it is usually necessary to step 
through the procedure for accessing the materials. 
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These cues would be obvious if the meeting were face- 
to-face. For example, it would be helpful to know if 
somebody “leaves the room" or otherwise checks out of 
the discussion. It would also be useful to know if people 
are shaking their heads in disagreement, or if the shy 
participant is frantically motioning to say something. 
There is no effective way to do this, in my experience, 
except to periodically stop and specifically ask each 
participant to respond. Most collaboration software 
has a feature enabling the participants to express their 
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emotions, but most people use it only when prompted 
by the facilitator. 

Providing visual props during remote meetings is 
essential. Even the most patient participant will lose 
track of the conversation during a long telephone call. 
The ideal visual aid is an outline, PowerPoint slides for 
example, controlled by the facilitator using collabora- 
tion software. If the meeting is being conducted without 
collaboration software, the visual aids must be sent to 
each participant in advance. The facilitator should 
constantly check that everybody is "on the right page." 
I generally say something like: "We are looking at slide 
six. Is there anybody who does not have slide six?" 
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Remote meetings are best for updates and information 
sharing, but it is possible to effectively facilitate decisions 
with a little planning. Generally, the meeting leader needs 
to clearly state the proposed decision and then separately 
poll each participant for concurrence. Normally, there 
will be a range of responses, requiring the facilitator to 
restate the proposal and repeat the process. Several itera- 
tions may be required before a consensus is achieved. I 
usually confirm decisions by restating the conclusion as 
it will appear in the meeting notes and asking the partici- 
pants to express any objections. 
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Gaining commitment to follow-up actions is never easy, 
of course, but tends to be particularly tricky in remote 
meetings. The ideal solution is to use collaboration 
software with a whiteboard as a means of recording 
the follow-up actions and responsibilities. (A Word or 
Excel document viewed through NetMeeting works 
equally well.) 

But if the meeting is being conducted without 
collaboration software, the leader must review each 
follow-up action explicitly, even painstakingly. I 
generally note follow-up actions throughout the meeting 
and use the last few minutes to confirm and finalize. I 
read each action and name the person I think owns the 
responsibility. When the person accepts, I validate by 
asking for a completion date. All the normal rules for 
assigning follow-up actions apply, of course. One, and 
only one, person must be responsible for each action, 
and assigning an action to somebody not present is akin 
to assigning it to nobody. 
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Documentation is good practice for any meeting, but 
it is essential for remote meetings. It is far too easy to 
misread the participants' reactions without being able 
to observe their body language. Did Mary drop out of the 
call because she lost interest , or because her cell phone died? 
Did Alfonso accidentally drop the phone, or throw it down in 
disgust? And who was that snoring anyway? 

I make it a habit to issue meeting notes within 24 
hours, preferably in the body of an email message (not 
as an attachment) to maximize the chance of it being 
read immediately. And I limit the meeting notes to the 
critical items I want to be sure we've agreed to, generally 
under just two headings: Conclusions and Follow-up 
Actions. If there is a need to inform others of what 
happened at a meeting, I do that separately. Confirming 
the participants have a common understanding of the 
outcome is absolutely essential to moving forward in a 
trustful environment, and it should never be confused 
with sharing the results with non-participants. 

I frequently hear complaints that remote meetings 
are ineffective. But in my experience, they can be just 
as effective as face-to-face meetings for most purposes. 
They just require more preparation. But with careful 
planning, and a little practice, you too will find yourself 
reminding people to "publish the call-in numbers." • 



HUGH WOODWARD 

concluded a 25-year 
career with Procter 
& Gamble in January 
2004. He spent 13 
years as a program manager in both 
manufacturing and business services 
environments at P&G, leading teams 
focused on operational and process 
improvement. He is now working 
with Macquarie Business Concepts 
to advise clients on approaches to 
achieve their strategic goals through 
the application of effective project 
portfolio management processes. 
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Bill Townsend 

Recently retiring from his position as Deputy Director of NASA’s 
Goddard Space Flight Center in Greenbelt, Maryland, Bill Townsend is 
now the Vice President and General Manager of Civil Space Systems of 
Ball Aerospace and Technologies Corporation. Prior to his assignment 
to Goddard in 1998, Mr. Townsend had served as the Deputy Associate 
Administrator (Programs) for the Office of Earth Science since 1993. 

For a 20-month period beginning June 1996, he was also the acting 
Associate Administrator for the Enterprise. 

Mr. Townsend also held other key positions within NASA, including the 
title of Deputy Director of the Earth Science Applications Division and 
the Chief of the Flight Programs Branch. He began his tenure at Wallops 
in 1963, and in addition to being recognized with various prestigious 
service awards, has been involved with close to sixty launches during 
the course of his NASA career. His story about the Aura launch was 
recently published in ASK 20. 
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INTERVIEW CONTINUED 


You recently had a story about your experiences with 
the Aura launch published in ASK. One of the most 
valuables lessons that came from it was the importance 
of listening to minority opinion. 


People need to recognize how important it is to listen 
to minority opinions. It doesn't mean you have to 
agree with them, but they should be heard. And this 
needs to happen at all levels of the organization. In this 
particular case, I had to seek out the minority opinion. 
When I heard that it might have some legitimacy, I 
wanted to hear more and take the time to discuss what 
was being said. 

I was asking, "Why are we seeing these things so 
late in the game?" Allegedly, we'd never seen them 
before, so why were they coming up in the launch 
sequence? It turned out that they had been there all 
along, but we hadn't seen it in the data. It was the 
dissenting opinion that caused us to go back and look 
at the test data again. 

If you are lower down in the organization, 
sometimes it's hard to raise your hand and say, “We've 
got a problem here." It is the same kind of thing that 
was discussed in the CAIB report. You've got people 
who are afraid that they are wrong, and they don't want 
to be embarrassed in front of their peers. That's why at 
Goddard we always insist that there are senior people 
onsite, involved, and ready to act for all our launches to 
make sure that no viewpoint gets overlooked. 


This story, especially in reference to the CAIB report, 
reinforces the importance of establishing a culture that 
respects minority opinion. 


Sure, because sometimes it's tempting to ignore the 
small voice. People get caught up in what I call “launch 
fever." Regardless of what's going on, people just want 
to launch. They get caught up in the quick tempo of 
things during the countdown. 

This discussion where I was able to elicit the 
dissenting opinion took place only an hour before 
launch — which is the height of “launch fever." It was a 
case where senior management had to step in and make 
a decision. So I decided to stop the launch. 


“I will take real, live 
experience any day 
of the week over 
a textbook, or 
classroom-type 
training.” 


prepared for launch, there were issues that needed to 
be resolved. 

During launch countdowns, I typically keep five 
or six channels open so I can hear what is going on 
across the board. Those almost sixty launches you 
mentioned have taught me that when everything is 
going well, the net is really quiet. When things aren't 
going well, people are talking constantly. In this 
particular case, there was chatter all over the place. 
As the countdown continued, it only got worse. It 
got down to about ten minutes, and I just had a gut 
instinct that we needed to stop the launch and assess 
where we were. So I did. 

We fixed our problems and launched the next 
night without any issues. It's tough, but as a manager 
you have to hold out against “launch fever." I have 
a motto I follow, which I've adopted from the wine 
industry: “No launch before its time." 


You T ve been involved with almost sixty launches , over What can you conclude from these cases regarding risk 


half of which were at Goddard. Were there any other 
times when you had to make the tough decision of 
postponing a launch? 


and decision making during a launch? 


It is a real fallacy that it is possible to drive risk to zero. 
Anybody who thinks that there is no risk in this business, 


Another situation was a NOAA launch some years has never worked in this business. Everything we do has 

ago. It was an entirely different situation, but as we residual risk associated with it. Senior Management has 
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Goddard Space Flight Center's launch phase simulator 


to make judgment calls. They have to ask, "Is the risk 
low enough that we can go forward with this? Do we 
have a reasonable chance at being successful?" 

For example, in a perfect world, people would say 
that you don't launch until you find the flashlight. But 
we held a full investigation: tracked people down as far 
as Holland, looked at photographic evidence — even 
checked the trash dump to see if we'd accidentally 
thrown it away. The spacecraft was the size of a small 
school bus, and the flashlight was a little penlight. 
When it came down to it, 1 thought the evidence was 
overwhelming that the flashlight was not on the space- 
craft, so I decided to launch. 


Your decision turned out to be the right one f since the 
launch was ultimately a success. Have you ever made 
decisions on a project that you later wished you'd done 
differently? 


Yes. There was a program called the Advanced Airborne 
Flight Experiment Program (AAFE). I proposed an 
aircraft instrument development effort, it was selected, 
and it came out very well. Then I proposed to augment 
the system. It is, in my opinion, one of my more notable 
career failures that I could never get this augmentation 
to work. 


Probably what happened is that I was so deep in the 
forest that I couldn't see my way out for the trees. I really 
needed somebody to have said, "Give it up. This is good 
money after bad. You're not going to get anywhere." 

Then again, I don't think you can become a top- 
notch project manager who is recognized as somebody 
to emulate without having made some mistakes. A 
classroom definitely doesn't provide everything you 
need to know to be a good project manager. 


What kind ofrole r then , do you think that training and 
certification of project managers plays? 


I will take real, live experience any day of the week over 
a textbook, classroom-type training experience. Don't 
get me wrong: Training has its place. It's important, 
there is no doubt about that. But you can't become a 
project manager by going to a class. There has to be 
a balance. 


Is there an Apprentice Program at Goddard so people 
can get that important hands-on experience? 


We are part of NASA's Summer High School 
Apprenticeship Research Program (SHARP) which allows 
students the opportunity to become apprentices to scien- 
tists and engineers at various centers across the country. 
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For our in-house employees, the kinds of experi- 
ences that build good project managers are different for 
each person. Sometimes we let people learn on smaller 
projects as a training ground. Or we might let them 
work on a larger project, but under a more experienced 
Project Manager. 

They've got to have the opportunity to learn the 
whole experience. I think we grow people at Goddard 
very well, partly because we have so many opportunities 
for our people. At any given time we have about three 
dozen missions in formulation, two dozen in active 
development, and another couple of dozen in opera- 
tions. There is a wide breadth of activity here. The 
main thing we've tried to continually work on is to 
grow people into being able to successfully assume 
positions associated with all stages of a project. 


Do you think that it is important to have an open-door 
management style so that people can get the support they 
need beyond training an experience? 


Absolutely. And then it's the management's job to 
provide the support needed along those lines. I never 
turn down requests for that kind of consultation, and 
people know I'm willing to do that. When people give 
me feedback about how my advice helped them, it 
reinforces my motivations for giving it. 

Not too long ago there was a person who came to 
me that was interested in becoming a project manager. 
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The Aura Launch at Vandenburg Air Force Base. 


I told him that I didn't think he was ready. I said, "I 
just don't think you've had the right experiences yet to 
be put into that position." So I told him I'd like him 
to be a Deputy Project Manager on a larger project 
than the one he wanted to manage himself. I said, "Do 
that for a year or two, and we'll talk about a project 
management assignment." 

That's an important management role: evaluating 
people and assessing their needs and capabilities, and 


then placing them in a situation where 
necessary tools and experience. 


they cai 


can get the 


When you think hack on your career at NASA, can you 
think of anyone who mentored you? 


Well, I came to NASA right out of hi jh school. I had 
no interest at the time in going to college, so I went 
into an Electronic Technician Ap 
I did well in the program, and I g 
Wallops Flight Center Director at the 
He encouraged me to go to colie 
me understand the importance of 
completed the Apprentice Program 
engineering degree from Virginia Tc 
When I got back to Wallops, Bob 
the Center Director. Around 1970, t 
group to do space-borne radar 
Wallops didn't do a lot of developme 
saw some opportunities there and 
whose talents could be directed 
I was only six months out of 
in at the ground floor of this group 
successful space-borne radar syster 
Wallops to go to NASA Headquarte 
Krieger was the most instrumental per 



e Program, 
noticed by the 
, Bob Krieger. 
and helped 
education. I 
got an electrical 

was still 
set up a small 
Back then 
work, but he 
he had people 
it. 

:ge, and I got 
We build three 
s before I left 
s. For me, Bob 
on in my career. 


I've had other folks who have played i significant role 
in advancing my career, but without Bob Krieger, it 
wouldn't have mattered. He took an interest in me and 
spent the time to help me understand my potential. 


Is there a specific moment that you remember about you, 
first job in a project management c 


When I was at Wallops, I was Expei 
for the SeaSat Radar Altimeter, w 
1978. I was sitting here at Goddard i 
a console in the Control Center on 
I gave the command personally to ti 
instrument on, and then all the v; 
came up on the screen. It worked, a 
It was an experience I'll never forget. 


riment Manager 
eh launched in 
"Building 14" at 
le second floor, 
n this particular 
ous parameters 
I was elated. 


from the editor-in-chief Dr. Alexander Laufer 



Shared Voyage: Encouraging Unlearning 


In recent years, more and more leaders 
of private and public organizations alike 
have realized that knowledge is the chief 
asset of organizations and the key to 
maintaining a sustainable and competi- 
tive advantage. Organizational learning 
means the continuous acquisition and testing of experi- 
ence and the transformation of that experience into 
knowledge that is made accessible to everyone within 
the organization. 

However, creating a "learning organization" is only 
half the solution. In addition to the familiar "learning 
curve," companies should establish a "forgetting curve," 
which is the rate at which a company can unlearn those 
habits that hinder future success. Pursuing unlearning, 
however, is not easy. First, very often people are simply 
unaware of the need to unlearn (e.g., they are unaware that 
the old assumptions regarding the world have changed), 
and, second, it is always difficult to undergo a change. 

The following examples, taken from Shared Voyage , 
show just how difficult it can be. Shared Voyage: Learning 
and Unlearning from Remarkable Projects focuses on 
four projects: the Advanced Composition Explorer 
(NASA), the Joint Air-to-Surface Standoff Missile 
(U.S. Air Force), the Pathfinder Solar- Powered 
Airplane (NASA), and the Advanced Medium Range 
Air-to-Air Missile (U.S. Air Force). Each project is 
presented as a case study comprises stories collected 
from key members of the project teams. The book 
which was co-authored by A. Laufer, T. Post and 
E. Hoffman, was recently published by the NASA 
History Office. One of the main objectives of the book 
is to encourage unlearning of outdated concepts. 

Sometimes it takes another person to help you 
change your mind-set. During the integration and test 
phase of the Advanced Composition Explorer (ACE) 
project, the Applied Physics Laboratory (APL) fell behind. 
NASA Project Manager Don Margolies thought that the 
way to deal with it was to order their team to work either 
weekends or double shifts. But Mary Chiu, APL Project 
Manager, was steadfastly opposed to telling her people to 


work overtime. Her people were salaried, and she wasn't 
going to order them to put in more hours. 

They argued about it for a while, finally asking the 
Chief Engineer at APL to join them for a meeting of 
minds. Don hoped that meeting would not turn into 
a very divisive discussion. What happened instead was 
that Mary pointed out something to Don that he realized 
should have been a no-brainer. In fact, it was then so 
obvious to him that he was embarrassed that he hadn't 
realized it himself. "All we have to do is make it known 
that we are behind schedule," Mary said. "Professionals 
don't have to be reminded that they have a job to do... 
they will rise to the challenge on their own." 

Realizing she was right, Don went back and told 
NASA management what Mary had said. She couldn't 
put the extra hours on the schedule, but she'd assured 
him that the work would get done. Ultimately, they 
recovered the lost time. Don knew that Mary had taught 
him a lesson in basic psychology: it's always better to let 
people come up with a good idea and implement it, than 
for you to force it down their throat. 

At times, the role of leaders is to help their team 
change their mind-set. During source selections for 
the Joint Air-to-Surface Standoff Missile (JASSM) 
project, Air Force Program Director Terry Little told 
the team that he wanted this phase to be completed 
in six months. Truth be told, he would've been happy 
with seven, or even eight — but he wanted to set almost 
unrealistic goals. Why? "I didn't want a schedule 
that the team felt they could achieve just by working 
weekends or figuring out a handful of inventive ways 
to do things," he said. "I wanted something so outra- 
geous that it would cause them to at first, give up — and 
then, to step back and examine their assumptions, their 
beliefs, everything they'd learned from past experiences 
and ask themselves with a clean slate: what do I really 
need to do to achieve this goal?" 

And that's exactly what they did. The team actually 
completed the source selection in five months. "When 
we talked about it afterwards," Terry said, "the team 
discovered that they hadn't known how capable they 
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could be if they just quit thinking about things in the 
way they had always thought of them." 

Of course, sometimes teams are not ready to think 
of things in new ways. The Advanced Medium Range 
Air-to-Air Missile program had been around for 20 
years, and Program Director Judy Stokley knew it was 
time for a major reform. 

It wasn't easy because of the type of partnership her 
team had with the contractor. If the contractor needed 
to change something, he had to submit an Engineering 
Change Proposal, and the government had to approve 
it. The contractor documented every change in parts, 
down to the lowest-level nut, bolt, or screw, and sent 
change proposals all day long. The government paid 
him to make those changes, or they didn't get done. 
Judy used to say, "If I want my contractor to flush the 
toilet in Tucson, I have to write him a contract letter 
and pay him to do it." 

She wanted very much to change that mindset, 
and get the contractors to have a "heart and soul" 
relationship with their products. If they could write a 
good, simple set of performance specifications that the 
contractor would control, and the government would 
pay a fair price for the product, Judy believed it could be 
a win-win situation for both sides. 

But she also didn't want any claims against her. 
The program had been under litigation for one thing 
or another since it started. When Judy took over as the 
Program Director, there were twelve standing requests 
for equitable adjustment filed by the contractors. She 
told the contractors straight out that she couldn't team 
with people who filed claims against her. She told them, 
"I'm going to help you pay for everything, I'm going to 
help you make a decent profit, and you are going to 
make sure that we have a good product out there." 

At a meeting, she laid out all her plans for reform 
to the contractor, and at first she was met with a lot of 
nodding heads. Then, the contractor's Chief Engineer 
stood up and addressed his Vice President, "Boss, I've 
got to make sure that before you agree to this, you 
understand what she's saying. Because if you do, I don't 
think there's any way you'll agree to it." 

That's when the room became extremely tense. 
"Right now," the same contractor continued, "if we 
change something, the government pays. She's telling 
you that from now on if we change something, we pay." 
From that moment on, it was clear that the contractors 
would not embrace any type of change. Judy felt the urge 
to laugh out loud; the attitude of those in the room was 
indicative of the same problems plaguing the industry. 

Then, as a result of a merger with another company, 


the Vice President was replaced. The new leader was 
able to see the opportunities of Judy's reform plans, and 
together they transformed the mind-set and behavior of 
their teams. 

Even though it may be difficult to convince others 
to "unlearn" old habits, the hardest thing can be 
to "unlearn" your own. In this issue of ASK , John 
DelFrate's article mentioned former AeroVironment 
Project Manager Ray Morgan and his struggle to 
overcome his tendency to micromanage. After managing 
a solar-powered flight project on which the young test 
pilot was nearly killed, Ray says he became "exactly the 
kind of boss that I said I would never be." 

Staying on at AeroVironment, he was working 
what should have been "the ultimate job." And yet some 
days he felt so much stress on the drive to work that he 
almost threw up. He tried to control every aspect of his 
projects, working up to 100 hours a week himself, and 
killing the morale of everyone he worked with. He had 
to control everything; nothing happened without his 
approval. People who had been so grateful to come to 
work for him were burned out in two or three years. He 
knew he'd have to either quit or find a solution. 

Around this time, Ray's wife saw a PBS special on 
Edward Deming, who had a revolutionary approach 
to management. He talked about incorporating "The 
Golden Rule" and the Scientific Method into your 
style. It was the first philosophy that really spoke to 
Ray, so he decided to take a night class at UCLA on 
the same topic. 

He saw his professor's teaching style that utilized 
the brains of the classroom, and he began to reflect 
on how he could do this within his own projects. He 
began the difficult task of "letting go" and admits that 
at first it was terrifying. But by the time he joined the 
ERAST team to develop Pathfinder, he says, "I was not 
only a different man, but a better manager. I had finally 
begun to be a leader, and was leading my division in a 
transformation that enabled me to draw full value from 
all of the brains of my workforce." 

Whether the concepts conveyed through these 
examples call for learning (that is, adding on new 
concepts), or for unlearning (that is, letting go of some 
old concepts), depends to a great extent on the set of 
beliefs that the particular project participant (or reader) 
has developed throughout his/her experience. One 
thing, however, is clear. Today, in our competitive and 
dynamic environment, everyone is expected to unlearn, 
and quite often. New ideas are breaking traditional 
molds and updating old axioms: "Live and unlearn ." 
"Gone and forgotten." • 
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